Delete More Than You Add

We're trained to build by adding. More features, more options, more code — progress is something you can see piling up. So the move I had to learn on purpose, the one that almost never comes naturally, is the opposite: removing. Not as cleanup after the real work, but as the work. Subtraction is a first-class act of design, and a net-negative change — fewer lines, fewer options, fewer moving parts, same result — is one of the most valuable things you can ship.

The reason it matters so much is that complexity is the thing that actually kills work over time. One useful definition: complexity is anything that makes a system hard to understand and change. It shows up as change amplification — one small intent forcing edits in five places — and as cognitive load, the amount you must hold in your head to touch anything safely. Both compound quietly, and both are attacked most directly not by adding cleverness but by taking things away.

Simple is not the same as easy

The trap is that we reach for easy — the familiar, the near-at-hand, the thing we already know how to bolt on — and mistake it for simple. They're different. Simple means un-braided: one concern, not tangled together with three others. Easy just means close to where you already stand. Adding the familiar option feels easy, and quietly braids one more thread into the knot; the simple move — pulling threads apart, deleting the one that didn't need to be there — is harder in the moment and far cheaper forever after. There's even a measured human bias here: offered a problem, people overwhelmingly reach to add and overlook the solution that removes. The standard worth keeping is the old one: a thing is finished not when there is nothing left to add, but when there is nothing left to take away.

Where it goes wrong

Subtraction is surgical, not reckless — the failure on one side is slash-and-burn, ripping out things that were quietly load-bearing because removal felt virtuous. Removing well means knowing what a part was holding up before you cut it. The failure on the other side, far more common, is the hoard: never deleting anything, keeping every option and dead branch “just in case,” until the system is mostly scaffolding around a small live core. The discipline is to treat deletion as a normal, frequent move — not a once-a-year purge, but a thing you do every time you notice something the work no longer needs.

Put it to work

This week, find one thing you can remove — a feature nobody uses, an option that only ever takes its default, a dependency pulled in for one function, a file that does nothing — and remove it. Sit with the result. Almost always the system gets clearer, not poorer, and you'll have felt directly the thing this principle is about: that taking away is how you make room for what matters.

Grounded in Rich Hickey's “Simple Made Easy,” John Ousterhout's A Philosophy of Software Design, Leidy Klotz's Subtract, and Saint-Exupéry's old standard for perfection.