Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.
— Edsger Dijkstra
Code is complex. Complexity is a battle that we all have to fight daily.
Of course, your code is great, isn’t it? It’s other people’s code that is complex.
Well, no. Not always. Admit it. It’s all too easy to write something complicated. It happens when you’re not paying attention. It happens when you don’t plan ahead sufficiently. It happens when you start working on a “simple” problem, but soon you’ve discovered so many corner cases that your simple algorithm has grown to reflect a labyrinth, ready to entrap an unwary programmer.
My observation is that software complexity stems from three main sources. Blobs. And lines.
And what you get when you combine them: people.
In this chapter, we’ll take a look at each of these and see what we can learn about writing better software.
The first part of software complexity we should consider relates to blobs: that is, the components we write. The size and number of those blobs determine complexity.
Some software complexity is a natural consequence of size; the larger a project becomes, the more blobs we need, the harder it is to comprehend, ...