Complexity vs. Simplicity
I was recently asked a question - “how do I simplify it?” The question took me back slightly as I didn’t really have a good answer. It took me a minute and I fudged it a bit, but the right answer should have been this:
“I attempt to visualise it somehow - if I can’t then it is likely too complex. I try breaking it down, and then breaking it down again until I can see it such that it looks good on a board and I can easily explain it.”
While a good question, the more interesting question for me is:
“Why do you simplify things?”
Many years ago, I read “No silver Bullet - Essence and Accidents of Software Engineering”* and I was introduced the difference between Necessary and Accidental Complexity. While necessary (or intrinsic) complexity is the amount of complexity required to solve a given problem, accidental (or incidental) complexity is anything that does not directly contribute to solving the problem. Some accidental complexity becomes necessary to facilitate the delivery of the solution while not directly contributing to it. The rest is just waste. Removing the waste, simplifies and allows us to completely focus on solving the problem without distraction.
The biggest lesson learned is that Simplicity and Complexity are not mutually exclusive. You can, and absolutely, should strive for the required amount of both. The simplest solution is the one that solves the problem with the minimal amount of accidental complexity.
There is another lesson that is implicit in this: Simple does not equal Easy. In many other contexts this may be the case but for a non-trivial problem the solution is equally non-trivial.
Simply being aware of these considerations has improved my ability to deliver valuable software both as an engineer and as an architect. I do tend to focus on simplicity. I break down a problem into smaller manageable chunks, designing solutions to solve those parts while managing to take the whole picture into account. It’s something I am good at. Something that I can actually visualise quickly, then spend time articulating and refining. I believe it is one of the key deliverables of a software/solutions architect - designing and delivering the simplest solution for the problem at hand.
It isn’t a great leap to consider that Accidental Complexity isn’t unique to Software Engineering problems, it can happen occur with any solution and act as a drag on solving the problem. Taking this into that context can be extremely beneficial.
Find out more:
- * No silver Bullet - Essence and Accidents of Software Engineering, Fred Brooks, 1986, Published in Mythical Man Month (anniversary edition)
- Simple Made Easy - Rick Hickey [InfoQ Presentation]
- Intrinsic and Incidental complexity - Noah Sussman
