Simplicity is prerequisite for reliability.
Edsger W. Dijkstra, How do we tell truths that might hurt? (1975)
In over 2 decades of professionally working on systems of various sizes and over 4 decades of using and sometimes suffering them, one thing holds true: the more complexity you add, the more that can go wrong. I mean - just look at Microsoft Windows.
The picture to the left, as an example, is pretty impressive. Now imagine you just want a cup of coffee. Suddenly, that could probably be considered overengineering. It gets worse when you consider someone built it, someone maintains it, and it probably takes a lot of energy to run for a simple cup of coffee.
I'm pretty sure that the system on the left doesn't make coffee. If you just want a cup of coffee, there are much simpler ways of getting it.
When it comes to systems, it's very easy to get wrapped up in complexity - particularly in an era when new ways to do things fly past at an increasing rate. We who love technology love trying to apply new technology to old problems and we do so successfully - but not always efficiently.
In the context of software development, it's not a new topic - in fact, Max Kanat-Alexander wrote a great blog entry on overengineering back in 2008. And of course, Max wrote Code Simplicity: The Fundamentals of Software.
This also ties in to my post on Simplicity and Complexity: Managing Expectations.
Because You Can Doesn't Mean You Should
I've been a geek for quite a long time - so long ago that I used to write code on paper so I could enter it on a timeshared System 36. New and exciting technology is always... new... ad it's always... exciting. At least for geeks. We'll see some new language, programming library, piece of hardware or process and immediately want to solve the world's problems with them. If you're playing around at home, it's all well and good - I have quite a few different projects I revisit depending on what interests me at the time - but when it comes to building systems that people depend on, we have to be a bit more conservative in our approach.
Pragmatism is the ultimate judge. When judging a new technology and it's use in a project, it boils down to this:
- Will it work?
- Will it add needed features?
- Will the new features balance maintenance costs/efforts?
- Is there a simpler way to get the same result?
Will It Work?
Typically the answer to this question is a resounding 'yes', but that answer may not necessarily be true. The most dangerous part of any part of any project is where system requirements are shifted slightly to meet the need of we geeks who want to play with a new technology - and because it's shiny and new, it's easy to sell - not because it's what people want, but because an excited geek is a better salesperson.
A better salesperson does not mean a better product.
Will It Add Needed Features?
Of course it will!
Well, maybe not.
We often forget that more features can put a user off - and that really is the issue. As much as a system might meet requirements for doing something, if the users are overwhelmed with features it becomes problematic. 'Needed' is a very relative word and needs to be grounded. If it's seemless to the users, that's great - but is there a simpler approach that is more efficient and doesn't use that shiny new technology? If there is a simpler approach, maybe that's the way to go..
Will the new features balance maintenance costs/efforts?
This is where many engineers, developers and other folks get lost because we either don't play well with the bean-counters or don't care. To make matters worse, we have to be honest: adding new features that guarantee job maintenance is a great way to assure job security in a world that doesn't really put the words 'job' and 'security' together very often.
There's also the issue that new technologies, after the initial hype, might be abandoned or become problematic to support. We don't like to talk about those failures but they are a reality. We also don't talk about the fact that a popular technology isn't necessarily the best technology, and so on.
In the end, one has to really look toward the future and make serious calculated decisions.
Is there a simpler way to get the same result?
As Thoreau wrote, "Distrust any enterprise that requires new clothes". The same applies to technologies - there are often ways that are time tested that work just as well and don't require investment (financial or otherwise) in new technologies. While everyone wants to be on the good side of the cutting edge, very few understand that it's also the bleeding edge and that the bleeding edge is... bloody.
Not a Naysayer.
The point is that when you're working on a project, you have to consider whether the risk of adapting a new technology is worth it - and for those easily blinded by shiny new technologies (SQUIRREL!), it's particularly problematic - I still fall into the trap myself on a personal level.
On a professional level, I've learned to avoid it with some severe pragmatism, some of it hard won.