Over-engineer?

"The problem with patterns, best practices, and idioms is the overuse of a single principle. Regardless of what you are considering, overuse of DRY (Don't Repeat Yourself) 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. :-)."
- http://java.dzone.com/news/first-indicators-overengineere


"Not many Java developers could sit down and start coding without thinking about a billion of side effects of doing so or being criticized for not doing so - directly or indirectly through very smart magazine articles with very cool approaches and rules. You simply don't have a chance to develop - you must engineer. In most cases it means that you over-engineer because of the fear of doing that wrong or the blindness to do it simple. And it is completely uncool to have a simple solution. It's cool to have a beauty monster."
- http://archi-jab-ture.blogspot.com/2009_03_01_archive.html


"Programmers should take a 'simple is best' approach to software design. Whenever a new piece of code is written, the author should ask themselves 'is there a simpler way to introduce the same functionality?'. If the answer is yes, the simpler course should be chosen. Refactoring should also be used, to make complex code simpler."
- http://en.wikipedia.org/wiki/Extreme_programming_practices


The story of Kingdom of Nouns
- http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html