We celebrate engineers who ship features. We track lines of code added. We measure velocity in story points delivered. But some of the most valuable work an engineering team can do is the opposite: removing code that no longer serves a purpose.
The Weight of Legacy Code
Every line of code in your codebase is a liability. It needs to be read when debugging. It needs to be considered when making changes. It needs to be tested, secured, and maintained. Code that exists but serves no purpose is pure cost with no benefit.
Yet most organizations never delete anything. Features get deprecated but the code stays. Experiments end but the branches remain. Over time, the codebase becomes a museum of every idea anyone ever had, and navigating it becomes increasingly painful.
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." — Martin Fowler
Why Deletion is Hard
If removing unused code is so valuable, why does it happen so rarely? A few reasons:
- Fear of breaking something. "What if someone is using this?" is a reasonable concern when you lack visibility into how code is actually used.
- No glory in deletion. Nobody gets promoted for removing features. The incentives all point toward adding, not subtracting.
- Emotional attachment. "I spent three weeks building that" makes it hard to hit delete, even when the feature never found product-market fit.
- Lack of clarity. In many codebases, it is genuinely hard to tell what is still needed and what is vestigial.
Making Deletion Safe
The key to confidently deleting code is having the information you need to know what is safe to remove:
- Feature flags with usage tracking. When you can see that nobody has triggered a feature flag in six months, deletion becomes easy.
- Dead code analysis. Static analysis tools can identify code that is literally unreachable.
- Runtime monitoring. Instrument your code to track what actually gets called in production.
- Deprecation periods. Mark code as deprecated, wait a month, then delete. If nobody complains, it was safe.
Building a Culture of Deletion
The best engineering teams we have worked with actively celebrate code deletion. They set goals for reducing codebase size. They track "lines deleted" alongside "lines added." They dedicate time specifically to pruning.
Some practices that help:
- Every PR that adds code should consider what could be removed to make room for it.
- Quarterly "deletion days" where teams specifically hunt for code to remove.
- Public celebration when someone removes a particularly gnarly piece of legacy code.
The Reward
Codebases that are regularly pruned are easier to work with. New team members onboard faster. Changes are less risky because there is less surface area to break. Build times decrease. Test suites run faster.
The best feature you will ever ship might be the one you delete.