I wish we could replace the posted article with your comment. I'm all for articles that challenge the way things are done and that cause us to reflect on why

I wish we could replace the posted article with your comment. I'm all for articles that challenge the way things are done and that cause us to reflect on why we are doing the things we are doing to make sure we're not cargo-culting - but this article is pretty bad for more reasons than I care to list. Your comment is great, though, and hopefully will find its way to the top of the thread. People often get caught up in "the one true way to do things" mentality. This is engineering, they think, so there must be a single, indisputable, scientifically provable, ISO standardizable correct way to write software. Once I know the one true way, I can mechanically apply it and not have to think about it anymore. Someone who subscribes to that mentality might go about creating a lot of ThingDoers with doTheThing() methods. In the name of never creating dependencies to concrete classes and having 100% test coverage, it is possible to lose perspective of what is important. If you've made your system less understandable and maintainable than a monolithic procedural class, you've missed the point. Related functionality needs to remain grouped together for understandability. Abstraction seams need to be created in ways and in places where it makes sense, not mindlessly to every single method in a system. This is more of an art than a science. One thing that I always keep in the back of my mind is FizzBuzzEnterpriseEdition. It's an absurd example of thoughtless one-true-way architecture taken to its extreme, making an extremely simple task incomprehensible but "pure." If I'm ever writing code and FizzBuzzEnterpriseEdition pops into my head, I stop and evaluate what I'm doing. The fact is that in this field there is no autopilot and constant reflection and adaptation is required. What works in one scenario doesn't always work in another. What works with one codebase doesn't necessarily work in another. What works with one team doesn't necessarily work with another. Even if it worked phenomenally well in one situation, with one codebase, or with one team. This applies not only to design patterns but pretty much all aspects of this business.