Book Club 3/2024: Simplicity

25 March 2024 4 Minutes History

Everything is too complicated.


This is a post in my Book Club Series.

My book club is a montly topical, curated list of things I've been reading, watching, or sometimes writing sent out via my email newsletter.

If you'd like to follow along with my book club, please subscribe; I won't email you more than once a month.

Everything is too complicated. Not just in software, everything! This isn't a novel concept, Teddy Roosevelt would have us believe that anything worth doing involves difficulty. I think this is a widely-adopted notion; simplicity in software seems to be a whole genre of software blogs. That makes my job here of sharing links quite easy though!

To spare all of the usual writing, simplicity is software is valuable because it makes all the things better. Simple code is easier to read! It's easier to maintain! Your code will perform 10x faster if it's simple! Simple code is more extensible, testable, and debuggable! Then we might consider the software itself - the UI, UX, and all the user-considerations. Simple software is easier to use! Users are less likely to reach an unintended state with simple software! You'll have fewer support calls and lower burden of feature growth with simple software!

These are all true, but a trap a lot of us fall into is neglecting complexity. Sure, our software could be extremely simple, but it has to solve real user requirements. This is the main source of complexity. Sometimes a very simple piece of software can solve most requirements of most users mostly well. Sometimes a more complicated piece of software can solve those requirements very well. We can't let ourselves want software more simple than the use case requires. I could just as easily rattle off plenty of pro-complexity platitudes: Complexity is necessary for real-world scenarios! Complexity is required to adequately address security and performance concerns! Architectures that maximize extension and innovation are necessarily complex!

Both simplicity and complexity are necessary. The difference here is that the necessity of complexity always comes with that asterisk - the kind and level of complexity that is required is the minimal amount required to satisfy the requirements you have for your system. Any complexity too far beyond that is detrimental; all of the listed benefits of simplicity are, in fact, true.

Understanding requirements is essential then. User requirements only capture so much. What are the environmental requirements? What quality attributes does the code need to support? These can introduce necessary complexity but often go overlooked. A complete understanding of the requirements of the code will allow you to develop a holistic view of the complexity that you need to introduce. This is a sort of focused complexity - this is not just complexity that is necessary but that is also understood; you know why it's there. Unfocused complexity is surely just as bad as excessive complexity. No doubt we all have codebases that have the wrong level of complexity, but ask also whether they have the wrong kind of complexity. Maybe indeed the level of complexity is right but it's unfocused.


And surely Jonathan Blow has something to say on the topic.


These two are kind of related:

From Me

I've had a couple articles recently that more or less relate to "simplicity":

Hi, I'm Ian

I'm a software engineer, architect, and team leader in Minneapolis. My career has largely focused on .NET and web technologies, spread across several industries. Currently I'm working for Crate & Barrel on their ecommerce solutions. You can find me on this blog, contributing to open source repositories, and at conferences around the Midwest.

If you'd like to keep up with me, please subscribe to my book club or RSS feed. If you'd like to help me out with server costs, I would be forever grateful if you bought me a coffee!

Some other posts you might be interested in: