The deprecation nobody owns

Every mature system contains a stratum of things that are officially dead and operationally alive: the v1 API "sunset" two years ago that still serves the biggest customer, the feature flag from a 2021 experiment, the cron job nobody dares stop because its author left and its output might matter. Deprecated is a status. Deleted is an achievement. The gap between them is where engineering organizations quietly store their risk.

The gap exists because removal is the only lifecycle phase with no natural constituency. Building has sponsors; running has an on-call rotation; even migration has a destination team cheering. Removal has a cost, a risk, and no one whose quarter improves when it happens. So the org's incentive gradient points one direction: things get added at the speed of ambition and removed at the speed of embarrassment.

The carrying cost is real but illegible, which is the problem. Every undead endpoint is attack surface the security team must reason about, a compatibility constraint on every refactor, a thing the new hire must learn exists before learning it should not. Worse, undead systems bite on schedule: the certificate expires, the deprecated dependency turns out to be load-bearing during an upgrade, the "unused" table is discovered to feed a regulatory report, usually by an audit rather than a plan. None of this appears on a roadmap until it appears on an incident review.

Organizations that manage the gap well treat removal as a product with an owner, and their practices rhyme. Deprecation announcements carry dates and diffstats: not "v1 is deprecated" but "v1 returns 410 on March 1, here are your three call sites." Usage measurement precedes every sunset, because the alternative is negotiating with ghosts; half the terror of removal evaporates when the access logs show the terrifying endpoint served four requests last quarter, all from the uptime checker. And someone's job description contains the word. Google, whose deprecation culture is publicly mocked and privately envied, is at least honest that the work is a discipline: the SWE book gives it an entire chapter, on the reasoning that at sufficient scale, undeleted code is unfunded liability.

There is a design-time corollary that costs almost nothing: build the exit while building the entrance. An endpoint that ships with usage attribution, an owner annotation and a kill switch is removable by procedure; one that ships bare is removable by séance. Teams that adopted "how does this die" as a design-review question report the question is unpopular for one quarter and then becomes furniture, which is how all good hygiene ends up.

The deeper observation is about what an organization believes finished means. A feature is not finished when it ships; it is finished when its predecessor is gone, because until then the org is paying for two answers to one question. Counting the undead, even once, even roughly, tends to be radicalizing. Most shops that do it discover they are running a second, invisible company whose only product is compatibility with their own past. That company has no customers. It should be wound down like any other bad business, deliberately, on a schedule, by someone paid to do it.