The metric every engineering team quietly optimizes for is lines added. It shows up in PR sizes, in sprint reports, in the vague sense of who is "producing." Nobody says this out loud, because saying it out loud would reveal how silly it is, but the incentive is real and it shapes behavior.
The best engineers we know produce a net-negative line count over the course of a year. They add code where it is needed. They delete much more of it elsewhere. The codebase, on the other side of their work, is smaller and does more. This is not a metric anyone tracks, and it should be.
Why deletion is undervalued
Deletion is undervalued because it is invisible in every artifact the team looks at. The PR that deletes 400 lines of dead code looks smaller in the review dashboard than the PR that adds 40 lines of a new feature. The sprint report has a column for stories shipped, not for stories retired. The performance review asks what you built, not what you removed.
All of these instruments were designed for an era when the scarce resource was code produced. That era ended a while ago. The scarce resource now is code understood, and every line you delete is a line that no future engineer has to read, debug, or route around.
The compounding value of a smaller codebase
A smaller codebase is not linearly better. It is superlinearly better, because complexity in software scales badly. Two systems of 10,000 lines each are not equivalent to one system of 20,000 lines. They are much easier to reason about, because the coupling between them is bounded. The 20,000-line system has, by default, 20,000 lines of potential coupling with itself.
Deletion reduces this in a way that no other activity does. Refactoring redistributes complexity. Testing constrains complexity. Documentation explains complexity. Only deletion removes it. And removed complexity is the only kind you don't have to keep managing.
What great deleters do
The engineers who delete well share a few habits.
They read code as a first move, not a last resort. Before they add anything, they look at what is already there, and they notice how much of it is dead — code that runs but produces no observable value, code that once handled a case that no longer exists, code that was written defensively for a threat model that turned out not to apply.
They are patient about proving code is dead. They do not just delete things that look unused. They add instrumentation, wait, and then delete based on evidence. The instrumentation period is the boring part of the work, and it is the part that separates careful deletion from the kind of deletion that causes an incident.
They write commit messages that explain what they removed and why. This sounds obvious. Almost nobody does it. Six months later, someone will ask why the feature is gone, and the commit message is the only place the answer is preserved.
What teams should do
Teams that want to encourage deletion have to protect it explicitly, because the default incentives will punish it. This means:
Reviewing deletion PRs with the same seriousness as addition PRs. A deletion of 500 lines is a substantial change and deserves the same care in review.
Celebrating deletions in the same channels where new features get celebrated. If the team's release notes list every feature and no removals, the team is teaching itself that removals do not count.
Giving senior engineers time to delete. The engineers most capable of confident deletion are also the ones under the most pressure to ship new work. Explicitly carving out time for cleanup is the only way it happens consistently.
A closing thought
We think about this at Fewzon because we are, at this stage, mostly writing new code. There is not much to delete yet. But the habits form now, in the first months of the codebase, and the deletion instinct is one we are trying to develop before the code gets large enough to hide from us.
The smallest, sharpest tools we admire were built by people who spent a lot of time removing what they had already built. We would like to be that kind of team.