Deleting code is the highest-value work nobody schedules

The most valuable pull request I have ever reviewed removed eleven thousand lines and added forty.

Deleting code is the only refactoring that is unambiguously good. It cannot introduce a bug in the deleted code, because there is no deleted code. It reduces build time, test time, cognitive load, security surface, and the probability that someone reads the wrong thing.

And nobody schedules it.

what accumulates#

Dead code. Never called. Nobody noticed, because nothing fails when unused code exists.

Features nobody uses. Built for a customer who churned, an experiment that ended, a requirement that changed. Still there, still tested, still maintained, still appearing in every search result.

Abandoned abstractions. Someone built a plugin system for the second plugin, which was never written. Now every call goes through a registry that has one entry.

Configuration for conditions that no longer occur. A flag for a migration that completed in 2023.

Compatibility shims. For a version nobody runs, an API that was removed, a browser that no longer exists.

Tests for deleted behavior. Still running, still slow, testing something that cannot happen.

Vendored copies. Of a library that is now a real dependency.

Commented-out code. Always. Delete it. Git remembers.

how to find it#

Coverage, over a long window. Run coverage in production if your language supports it, or over your full integration suite. Anything at zero across a month is a candidate.

Be careful: zero coverage does not prove dead. It might be an error path, a rare branch, or something exercised only in a region you did not sample. Verify before deleting.

Static analysis for unreachable code. Most linters find unreferenced functions within a module. Cross-module dead code is harder and several tools do it.

Feature flags at 100% for over a quarter. The disabled branch is dead code with a switch on it.

Endpoints with no traffic. Log every route. Anything with zero requests in ninety days is a candidate. This is trivially easy to check and almost nobody does.

Deprecation warnings nobody triggers. If you have been logging a deprecation warning for a year and it has never fired, the deprecated thing is unused.

git log on the file. Anything untouched for three years in an actively developed codebase is either perfect or forgotten.

how to do it safely#

Log before you delete. For anything you are not certain about, add logging and wait. A month of zero calls is strong evidence.

def old_thing(x):
    log.warning("old_thing called", stack=traceback.format_stack())
    return new_thing(x)

Delete in a separate commit from any other change. A deletion mixed with a refactor is unreviewable and un-revertable.

Delete the tests too. Tests for deleted code are the most common thing left behind and they will confuse the next person enormously.

Do not comment it out. Do not move it to an old/ directory. Do not keep it "just in case." Git has it. If you genuinely might need it, note the commit hash in the deletion's commit message.

Do it in batches, by area. One area, fully cleaned, is better than a thousand scattered deletions that are impossible to review.

the resistance you will meet#

"What if we need it?" You will not. And if you do, it is in git. In many years I have never seen a team need to recover deleted code that they could not recover.

"Someone might be using it." Measure. That is what the logging is for. Guessing in either direction is worse than checking.

"It works, why touch it?" Because it costs. Every line is read by every person who greps this file, is compiled on every build, is scanned by every security tool, and is a possible place for a future bug.

"That is not a priority." Correct, and it never will be, which is why it has to be scheduled rather than prioritized. Ten percent of one sprint, quarterly, with a line count as the deliverable.

the framing that gets it done#

Make it a competition. Track lines removed. Celebrate the largest deletion of the quarter.

This is slightly silly and it works, because it inverts the default incentive. Engineers are implicitly rewarded for adding — features shipped, code written — and never for removing, even though removing is frequently worth more.

Naming it, tracking it, and praising it is enough to change the behavior.

the number#

A large fraction of most mature codebases is dead or effectively dead. I have never audited one where it was under 10%, and I have seen 40%.

Every line of that is being read, compiled, tested, scanned, and maintained, at a cost nobody has ever measured.

Go find some.