Every codebase of any age has a layer of things nobody is willing to touch. A feature flag from a rollout that finished two years ago. An endpoint that might still be called by a client somebody’s customer runs. A branch in the code guarded by a condition that may never be true anymore. Nobody defends these; if asked, everyone would agree they should probably go. They stay because deleting requires being sure, and being sure requires evidence that doesn’t exist.

That’s what makes dead code different from other kinds of mess. Most cleanup is a question of time — the work is understood and just hasn’t been prioritized. This one is a question of knowledge: the honest reason a thing survives is that the cost of being wrong (breaking a customer silently, discovering months later that the job did matter) is high, while the cost of leaving it is diffuse and paid by everyone slowly. Faced with an unbounded downside and a vague upside, leaving it alone is the rational individual choice, which is why it keeps being made.

Which means the useful intervention isn’t exhortation to be braver. It’s making the evidence available. If every endpoint records when it was last called and by whom, “is anything using this?” stops being a debate and becomes a query. If flags carry the date they were introduced and the decision they gated, the stale ones announce themselves. If a code path emits a marker the first time it’s hit in a period, silence over a long enough window is real evidence rather than an assumption. None of this is elaborate, and it converts the scariest deletions into ordinary ones.

There’s also a middle step that costs less than deleting and produces the same information: make the thing fail loudly instead of removing it. Log at a level someone will see, or return an error to a fraction of callers, or disable it behind a flag you can flip back in seconds. If nothing happens for a month, you’ve learned what you needed. If something does happen, you find out from your own instrumentation rather than from a customer, which is the entire difference between a controlled experiment and an incident.

The reason it’s worth the effort is that unremovable code isn’t inert — it’s a tax on comprehension. Every person reading that file has to work out whether the branch matters, every refactor has to preserve behavior nobody can explain, and every new feature has to interact with a system whose real surface area is larger than its useful one. The alternative isn’t recklessness. It’s arranging things so the question “does anyone actually use this?” has an answer that doesn’t depend on anyone’s memory.