The Discipline of Deleting Code

We measure a lot of things about our work, and almost all of them count up: lines written, features shipped, services launched. But the healthiest weeks we’ve had — the ones that left the system noticeably easier to live with — usually show up as a negative diff. We’ve started treating deletion not as cleanup, but as a first-class form of engineering.

What deleted code is worth

A line you remove is a line that can never again have a bug, never need a dependency bump, never get flagged in a security scan, never sit half-understood in a file the next person is afraid to touch. Working code has an ongoing cost just by existing — it has to be read, compiled, tested, reasoned around, and kept alive. Deletion is the only change that pays that cost back permanently.

Every line of code is a small liability you’re hoping turns into an asset. Most of the time you find out it was a liability all along. Deleting it is just settling the account.

Why it’s hard, and it’s not the code

The resistance to deleting is almost never technical. It’s psychological, and it comes in a few familiar shapes:

• Sunk cost. “Someone spent a week on this.” They did, and that week is gone whether or not the code stays. Keeping it doesn’t honour the effort; it just makes everyone after pay interest on it.
• “We might need it.” The graveyard of dead code is paved with “might.” Version control already remembers it perfectly. You are not deleting the code — you are moving it from the path the next reader has to walk, into history they can dig up in thirty seconds if the “might” ever arrives.
• Fear it’s load-bearing. This one is legitimate, and it’s the one worth spending effort on. The fix isn’t to keep everything — it’s to make deletion safe to attempt.

Make deletion cheap to try

The whole discipline rests on one capability: being able to remove something and find out, fast, whether anything noticed. That’s what a real test suite buys you. Not correctness for its own sake — the confidence to subtract.

# The most satisfying command in software.
$ git rm src/legacy/PricingEngineV1.cs
$ dotnet test

Passed!  - Failed: 0, Passed: 412, Skipped: 0

# Nobody was using it. It's gone, and the build is greener for it.

When the tests are strong, deletion stops being a gamble and becomes an experiment with an instant answer. You pull the thread; either the sweater holds or it unravels in the test runner, where unraveling is free. We delete because we test, not in spite of it.

A standing habit

We keep a small, standing invitation on every project: if you’re in a file and you spot something dead — a flag that’s permanently on, a branch nothing reaches, a helper with no callers — you don’t need a ticket. Delete it, run the suite, and send the diff. Some of our best-reviewed pull requests are pure red.

The constellation we’re named for isn’t made of all the stars in the sky. It’s made of the few worth keeping, and the dark between them is doing just as much of the work. A codebase is the same. What you leave out is what lets the rest be legible.