The case for deleting code

We measure progress by what we add: features shipped, commits made, files created. Rarely does anyone celebrate a pull request that removes two thousand lines. Yet that pull request may be the most valuable thing merged all quarter.

Every line of code is a liability with a small, permanent cost. It must be read by the next person, compiled, tested, upgraded when its dependencies change and reasoned about when something nearby breaks. Code that no longer earns its keep keeps charging rent anyway.

Why deletion is hard

Deleting is harder than writing because it requires certainty. To add a feature, you need to know what you want. To remove one, you need to know who still relies on it, and that knowledge is usually scattered across logs, memories and a customer nobody has heard from in a year.

So code accumulates. Flags that were meant to last a week last three years. Fallback paths for browsers nobody uses stay just in case. Each one is individually harmless. Together they make the codebase slower to change, which is the only kind of slow that really matters.

Make removal a habit

Treat deletion as normal work, not cleanup. When a feature launches, schedule the removal of its flag. When a migration finishes, delete the old path in the same week. Measure the codebase's health partly by how easily things can leave it.

Deletion as design

There is a deeper version of this habit that happens before any code is written. Every feature request carries an implicit question: could the need be met by removing something instead of adding something? A confusing settings page is often fixed by deleting half the settings. A slow workflow is often fixed by deleting a step that existed only to work around an older limitation.

This is uncomfortable because it requires saying no to things that someone once asked for. But products that only ever grow become museums of past decisions, each exhibit defended by whoever remembers why it was added. The people who suffer are new users, who must learn the whole museum before they can do anything useful.

AI-assisted coding makes this more urgent, not less. Generating code is now almost free. Understanding it, reviewing it and living with it are not. When the cost of writing falls to zero, the discipline of keeping a codebase small becomes the main thing separating systems that stay changeable from systems that quietly calcify.

The goal is not less code for its own sake. It is a system where everything that remains is there because someone, recently, decided it should be.