A few scattered thoughts on this, as someone who has recently made great personal strides out of the overengineering/overcomplicating zone: - Developers who wo

A few scattered thoughts on this, as someone who has recently made great personal strides out of the overengineering/overcomplicating zone: - Developers who work on business applications spend a lot of time reading about and understanding (and getting inspired by) the reusable libraries and frameworks they use, and very little time reading about and understanding other business applications. This is unfortunate, because the way that developer libraries and frameworks are specified, designed and abstracted is completely inappropriate for business applications. I think this is where the overuse of generics and constant drive for ever more perfect abstractions come from. - Metrics around unit tests also drive a lot of over-abstraction, as well as the "shallow wrappers" pattern he mentions. Every implementation needs an IImplementation so it's "unit testable", and because "what if we want to change implementations?" - I think there's an underlying fear that code that's "too easy" or not complex enough can't possibly be production quality, and that it's not deserving of the time of a team of professional developers unless it's complicated enough to need a full suite of unit tests, a dependency injection framework, and a bunch of helper libraries. - Point #9 says that "people go all the way around to even slightly fit into what's existing", but I think a lot of the drive for that comes from managers and metrics that reward "reuse" and leveraging the work of others, as well as the development of reusable components (nothing says "influence" like "my team built this library that management now demands the usage of.) - Finally, I think the mindset that object-oriented programming and domain-driven design puts people into, as well as a lot of cultural baggage in the industry around big-design-up-front, should take a big portion of the blame for a lot of overengineering of the type that the author discusses. We gotta think about all the possibilities up front and then abstract these concepts out of the domain into classes, and those classes need to be reusable and testable... and once everything is grouped together it's incredibly painful to refactor or move things around. My personal revelation has been to start thinking a bit more functionally, tending towards building things from the bottom up in small pieces and assembling them without worrying about grouping them together into classes that match the domain, and not being afraid to throw a few things away that turned out not to be useful.