First Indicators of an Over-Engineered Project

The problem with patterns, best practices, and idioms is the overuse of a single principle. Regardless of what you are considering, overuse of DRY can lead to "fat" layers and classes, overuse of Separation Of Concerns to many fine grained units, overuse of modularization to JAR, plugin, or just governance hell.

1. You start to use terms like "potentially", "in future", or "scalable".
2. You spend more time thinking of "encapsulation", "abstraction", and "decoupling", than the actual problem.
3. You believe that with the amount of frameworks, libraries, and languages (better polyglot projects), the quality of the software will improve.
4. You are able to replace every single concept, class and layer—but this feature actually cannot be derived from the client's requirements.
5. Just looking at the code—you do not understand what happens—you need additional tools, products, and consultants :-) to understand it.
6. You hate monolithic structures—so everything is configurable, replacable—of course, at runtime. If it becomes too complex, go to point 5.
7. You start to implement a generator to tackle the complexity.
8. Your configuration file is getting slightly bigger than your code.
9. Your interface is so fluent that only domain experts understand the code. :-)

Common sense and the balance between concepts and idioms are the solution—but it's hard to find in real world. :-).

From http://blog.adam-bien.com/