Obviously, some things need to be complex. But in my experience, most parts of a program are best left simple. There is the proverbial 80/20 rule for optimization. That is, 20 percent of the code will account for 80 percent of the running time. My experience is that it’s more like 90/10, or even 95/5.

The same holds true for simplicity: at least 90 percent of a project’s code can be written in a very simple and straightforward manner. It’s the height of folly to implement a highly complicated infrastructure to handle that other 10 percent (or less), and force the rest of the code to use that infrastructure.

There are many “principles” that have been put forward in an attempt to improve our craft, but have been elevated to the status of doctrine. As engineers this is increasingly imprinted upon each other as what good engineers do, such as “you must account for all eventualities!” or “you must validate data in every method!”.

The complexity of modern software has risen to such a level that it is reflexive for us to attempt practicing patterns that mitigate risk because we can’t grasp the whole of the system in our head at once. The problem with this is that it increases the level of complexity more often than decreases it.

In my experience we code production software once or twice, but support and extend it many many times over years of use. The benefit of simple self-evident code is multiplied in the real world and far exceeds the cost of occasionally paying that technical debt. The more layers of abstraction used to express the domain functionality in a piece of code, the more you must re-explore and keep in your head just to understand what your code is doing when you need to change it later.

I have heard many tales of large projects bogging down and failing, but can’t really think of any case in which a project failed because they kept the code simple.