Learning the programming art is like learning any other art. You first learn the rules (and even more importantly the REASON behind the rules). You then build t

Learning the programming art is like learning any other art. You first learn the rules (and even more importantly the REASON behind the rules). You then build the discipline of applying the rules. And finally through experience you learn where some of the rules just don't apply. The usual progression is something like: 1. Build your first major project as senior engineer. You make something that works, but is brittle and soon becomes difficult to work with. 2. Build your second major project. This time, you adhere to ALL established best practices. The end product is difficult to configure because you've gone too far in flexibility, and a major pain to maintain because the codebase is 3x larger than it needed to be, and filled to the brim with boilerplate code. You also resist changes that threaten the precious architecture. Everything's perfectly isolated and testable, though! 3. Build your third major project with the minimum needed to get it to work for your client, keeping a few of the best practices to keep it mostly flexible enough for changing requirements. It will eventually grow in unhealthy ways as requirements shift beyond fundamental architectural assumptions, but you already knew this going in. 4. Make the mistake of doing a "2.0" rewrite of your major project. Vow never to do it again.