Meet Good Design

In plain terms: software that’s easy to change without breaking what’s already there.

I hope you are starting to see the enemy. Complexity makes our systems hard to understand and hard to change — and left unchecked, it only compounds. But it helps to know not just what we’re fighting against, but what we’re fighting for. What does a system look like when complexity isn’t winning? What does it feel like to work in one?

Good design has a few common characteristics. They’re worth knowing, because they’re not just abstract ideals — they’re the goals that every tool and principle we’ll cover in this series is working toward.

The first thing you notice in a well-designed system is that it doesn’t ask too much of you. The information you need is clear and present. What a component does is apparent. You can reason about a part of the system without needing to hold the entire thing in your head — remember Ousterhout’s definition: anything that makes a system hard to understand and modify. A system that overwhelms you with things to know is a complex system, almost by definition.

Closely related is consistency. It operates at two levels. Within a component, consistency means the thing behaves predictably according to its own rules — you can learn how it works once and trust that it holds. Across the system, consistency means shared standards — naming conventions, patterns, error handling approaches — that make the codebase feel like it was written by one coherent mind rather than assembled from unrelated pieces. Independence gives different parts of a system the freedom to make their own decisions, but that freedom shouldn’t extend to arbitrariness. When different parts behave differently for no good reason, every part becomes its own puzzle. Inconsistency is a form of accidental complexity — it makes things harder to understand without making them any more capable. A consistent system respects the developer’s time and reduces the number of surprises.

The next cluster of qualities all relate to change — which makes sense, because software that can’t change gracefully is software that will become a burden. A well-designed system is flexible: you can change one part without disrupting the whole. The parts are independent enough to be worked on separately, to grow at their own pace, to be improved without requiring a coordinated effort across the entire codebase.

This flexibility is what makes a system stable. Stability here doesn’t mean frozen — it means that existing functionality is protected. When you add something new, you shouldn’t have to worry about what you might be breaking. When you fix a bug, the fix should stay contained. The risk of every change should be proportional to its scope, not amplified by hidden dependencies and tangled responsibilities.

Good design is also extendable. When a new requirement comes in, you shouldn’t have to rewrite what already exists — you should be able to build on it. This is one of the most practical tests of a design: can I add to this without dismantling it? Extendability is closely tied to reusability. Components that are focused and independent can be used in multiple places and contexts without being tailored to any specific one. You write something once, and it earns its keep many times over. Every time you reuse a well-designed component, you’re getting more value out of the original investment — and you’re not introducing new places for things to go wrong.

And then there’s testability. It might seem like a separate concern — a QA thing, not a design thing — but it’s actually one of the best signals of good design you have. It turns out that code that is clear, consistent, focused, and independent is also easy to test. You can test a component in isolation, without needing to set up the entire system around it. You can verify its behavior precisely and thoroughly. And when you have that kind of confidence in the individual parts, you have confidence in the whole. Testability isn’t just a nice-to-have — it’s a consequence of doing everything else right.

All of these qualities point toward the same thing. When your design is working, making a change means going to one place. Not one function or one line of code — that’s too literal. But one isolated, independent part of the system where the concern lives, where the change can be made, where it can be understood and tested without pulling the rest of the system into view. The change — whether it’s a new feature, a bug fix, a performance improvement, or a third-party integration — stays contained. The rest of the system doesn’t even notice.

That’s the goal. It’s optimistic, and real systems are messier than any ideal. But it’s a useful test: when you sit down to make a change, how many places do you have to touch? How much do you have to understand before you feel safe? The answer tells you a lot about the health of your design.

Now that we know what we’re fighting for, we can start talking about how to get there. The tools and principles we’ll cover from here aren’t abstract exercises — they’re the specific things that make these qualities possible. Each one is a way of pushing your design closer to the system you just read about.