When in doubt, delete it out

One of the most harmful human errors in large software systems is the gap between the perceived risk of deleting code and the actual risk of not deleting it.

I recently had the following conversation with my manager:

By trying to avoid a small risk - the 1% chance that the variable is used - my manager is creating a long-term risk. The risk of this unused code staying in the codebase indefinitely (or at least for another year or two). It clutters the code, increases mental overhead for every developer who sees it, and wastes time as the same question is asked again and again.

This is risk aversion leading to technical debt. It doesn’t eliminate risk, it just shifts it around and, in the end, adds to the total amount of risk we're carrying.

I’ve seen this play out in different forms. Peers stumble across unused functions but don’t delete them. The reasons vary: “We might need it one day” (or we might not), “It’s not part of my PR” (as if it’s part of any PR), or my favorite, “One day we’ll do a big cleanup” (that mythical day I have yet to witness).

So what can we do? How can we turn the herd of feared sheep in the right direction towards deletion?

Kent Beck’s TDD wonderland says it’s simple: delete code, run tests, and if none fail, you’re safe. Well, now all you have to do is refactor everything to be testable, write thousands of forgotten tests, and then finally delete that global variable used in about 10 if-statements containing (with 99% certainty) unused code. If that level of effort seems impractical, it’s because it is. So let’s consider the situation where you’re working in a large codebase without a strong safety net, because that’s the real world most of us live in.

My solution is written in big monospace font on all the walls: “When in doubt, delete it out.” A culture where the default isn't to preserve out of fear, but to clean up courageously out of principle. So the next time someone asks, “Should I delete it?”, the answer is already hidden in the doubt.

But courage alone isn’t a strategy.

To make this culture work, you need a different kind of safety net. Release in small steps. Have a simple rollback plan that rolls back when the 1% chance of something being needed hits. When the cost of mistakes is low, perceived risk shrinks. And when something does break, use that moment to create a test (with just enough refactoring). Keep doing this, and slowly, you’ll build your own version of Kent Beck’s TDD wonderland.

I’ve seen the complete opposite strategy to reduce risk. Introducing long-lived “stable” branches, endless versioning strategies, and a paralyzing fear of touching anything. But all of this just buries the original mess deeper. You’re not managing risk, you are postponing it. Maybe indefinitely. And at that point, don’t try to be a hero. Just walk away.

Because in a codebase ruled by fear, deletion is rebellion and the war chant is “When in doubt, delete it out.” But some rebellions aren't worth the burnout.