| When you make your code more flexible or sophisticated than it needs to be, you over-engineer it. Some programmers do this because they believe they know their system's future requirements. They reason that it's best to make a design more flexible or sophisticated today, so it can accommodate the needs of tomorrow. That sounds reasonable—if you happen to be psychic. If your predictions are wrong, you waste precious time and money. It's not uncommon to spend days or weeks fine-tuning an overly flexible or unnecessarily sophisticated software design, leaving you with less time to add new behavior or remove defects. What typically happens with code you produce in anticipation of needs that never materialize? It never gets removed. This happens either because it's inconvenient to remove the code or because you expect that one day the code might be needed. Regardless of the reason, as overly flexible or unnecessarily sophisticated code accumulates, you and the rest of the programmers on your team, especially new ones, must operate within a code base that's bigger and more complicated than it needs to be. To compensate, folks decide to work in discrete areas of a system. This seems to make their jobs easier, yet it has the unpleasant side effect of generating lots of duplicate code because everyone works in his or her own comfortable area of the system, rarely seeking elsewhere for code that already does what he or she needs. Over-engineered code affects productivity because when programmers inherit an over-engineered design, they must spend time learning the nuances of that design before they can comfortably extend or maintain it. Over-engineering tends to happen quietly; many architects and programmers aren't even aware they are doing it. And while their organizations may discern a decline in team productivity, few know that over-engineering plays a role in the problem. Perhaps the main reason programmers over-engineer is that they don't want to get stuck with a bad design. A bad design can weave its way so deeply into code that improving it becomes an enormous challenge. I've been there, and that's why up-front design with patterns appealed to me so much. | 
