Good designer

“A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.” — Antoine de Saint-Exupéry

Saint-Exupéry was writing about aircraft, but the principle applies everywhere design decisions are made under constraint. Including software.

The instinct in engineering is to add. Add a configuration option, add a fallback case, add a layer of abstraction for flexibility we might need someday. Addition feels like progress. The codebase grows, the feature list expands, the design accumulates. What’s harder to see is the compounding cost of everything that’s been added—the surface area of bugs, the cognitive load on anyone reading the code, the maintenance burden of every path that must be kept working.

Subtraction requires a different kind of confidence. To remove something, you have to believe that the system is better without it—that the simplicity gained outweighs whatever edge case or flexibility the removed thing was providing. That belief is often correct and frequently scary to act on.

The best software designs I’ve encountered share a quality with Saint-Exupéry’s observation: they feel inevitable. Not minimal in the sense of stripped down or incomplete, but minimal in the sense that you can’t see what you’d remove without losing something essential, and you can’t see what you’d add without adding complexity for its own sake. The design fits the problem cleanly.

Getting there almost always involves removing things. An early API with too many parameters. An abstraction that was solving a problem that never materialized. A configuration surface that was exposing internal complexity instead of hiding it. The design improves not by addition but by the discipline to cut.

Knowing what to cut—and having the confidence to cut it—is what separates a good designer from someone who’s just good at building.