On Overengineering
A little while ago a good friend architect of mine told me about a crazy over-engineered project he was working on; the application had two or more caching mechanisms, and took over a week for a new developer to get onboard. At a gig I had last year (and I’ve written about this) I worked on a project that had three persistence mechanisms and two dependency management mechanisms. A pure nightmare
How does this happen? Well, I think in a recent article I mentioned that one cause is human nature and the failure to really understand something, and thus dismiss that and put in their own solution. Now I am seeing a second cause: the need for demonstrate technical prowess for its own sake.
Recently I was approached by an architecture team to look at a home grown service bus mechanism –never mind that there were great solutions out there, they had a home grown one in the last year and blahbity blah blah. Situations like this re-inventing the wheel are nothing new but of course being an implementation type, I shot off several questions about maintainability, performance, and business ROI that I didn’t feel they were addressing.
It became clear that the team did not know how to refactor, and the team wanted to maintain creative control to the point that it was detrimental to their project.
Now on my projects I am not against a little bit of useful complexity. But with a lot of projects under my belt, and knowing its so rare to see something elegant, I started to scratch my head at a team that couldn’t even explain the fit of their created technology into their companies business!
Recently I have been reading the Cathedral and the Bazaar. In that book the author makes a statement, that Linus Torvold’s genius wasn’t creating complex hings so much as he kept things simple and did them well. This perpetuated Linux.
We see this pattern throughout the world. Simple, effective design like sharks and Armani suits survive the test of time. Design can definitely be complex, or not obvious. But complexity for complexity’s sake is a bad thing; its costly, its wasteful, and its ugly. Complexity is NOT innovation.
Its interesting to watch this code smell continue. Every month or so I hear from them, I guess we’ll see.