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.

Watching

• Large-Scale Architecture: The Unreasonable Effectiveness of Simplicity - Randy Shoup (2022)
• Managing Complexity in Software - Hadi Hariri and Kevlin Henney (2022)
• Software Architecture, Team Topologies and Complexity Science - James Lewis (2022)
• Highly Cohesive Software Design to tame Complexity - CodeOpinion

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

Reading

• Learn Code Complexity: Understanding Code Complexity with Ease - Mohit Trivedi
• Why embracing complexity is the real challenge in software today - Ken Mugrage
• Why Simple is So Complex - Joe Crick
• Software Complexity: Essential, Accidental and Incidental - Alex Bunardzic
• What Is Complexity? - Alex Kondov
• Simplifying Software Development - Dick Wall

These two are kind of related:

• Clean your codebase with basic information theory - Taylor Troesh
• Metric-centered and technology-independent architectural views for software comprehension - Luis F. Mendivelso, Kelly Garcés, and Rubby Casallas

From Me

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

• Just Use PostgreSQL
• It's Better to be Consistently Incorrect than Inconsistently Correct
• Eight Maxims