> "If you need to add anything else, it’s right here. No registration, no XML files. Just code. Your code." If it's your code, and yours alone, just do whateve

> "If you need to add anything else, it’s right here. No registration, no XML files. Just code. Your code." If it's your code, and yours alone, just do whatever. Simple and terse works great for small code-bases, developed by small teams with like-minded people that have similar tastes and backgrounds. Often, such small groups of people communicate so well with eachother that they also share an excellent common understanding of what they build across the stack. At some point both the team and the code-base will start growing. You'll need strong, opinionated frameworks in-place for accomodating this growth. Without those guardrails in-place, there's nothing preventing the code-base from growing in a thousand different directions. Often times a project starts without those frameworks in-place, because it's so much easier to jump straight into business logic and not waste any time on pesky factories, interfaces and enums. By the time new people come in and start contributing - it's already too late and you've racked up too much code to start fresh - might as-well just keep piling on. A snowball effect. Dependency Injection as presented in the "hold on to your hats" section of the article may seem ugly and overcomplicated - but is one of those patterns used to hold large codebase to a unified, repeatable and persistent standard. "Fun" was never a part of the equation.