Meet Complexity

In the last post, we talked about complexity in broad strokes — the idea that some of it is necessary, and some of it isn’t, and that software design is largely about eliminating what isn’t and controlling what is. But complexity is worth looking at more closely, because understanding what it actually is — and what it does to a system — is what makes the fight against it feel worth having. John Ousterhout, in A Philosophy of Software Design, gives a definition that has stuck with me: complexity is anything related to the structure of a software system that makes it hard to understand and modify. That’s it. Not a measure of how many lines of code you have, or how sophisticated the algorithm is, or how many services are running. Complexity is about how hard it is to work with. And that framing matters, because it makes complexity something you can feel — and something you can fight. So why does it matter if a system is hard to understand and modify? That might sound obvious, but it’s bec