The Veto Only Points One Way
Try to deprecate an old API version and watch what happens. Within a day, someone files a ticket because a reporting pipeline built against the old field names will break. A sales exec escalates because a customer mentioned it in a renewal call. The sunset date, announced with six months of notice, quietly becomes a year, then an open question nobody schedules a follow-up on. The version stays live, half-documented, mostly forgotten, until the only people who remember why it exists have left the company.
Now watch what happens when you add a new version instead. Nothing happens. It ships behind a flag, gets a changelog entry, and the cost of maintaining it doesn't land on anyone in particular, it gets spread across every future engineer who has to remember it's there. No one objects to a thing that hasn't cost them anything yet.
That asymmetry is the whole story. Removing a path converts a future, diffuse cost into a present, specific one, borne by someone who can name exactly what breaks and when. Adding a path does the opposite: it converts a decision anyone could have blocked into a cost nobody can quite locate, paid later, by whoever happens to be holding the codebase, the budget, or the org chart at the time.
A veto requires standing, and standing requires being a specific person with something you can point to losing, right now. Growth almost never produces that person. The beneficiaries of a new feature, a new tax credit, a new management layer, are hypothetical or distributed too thin to organize into an objection. The victims of removing one are never hypothetical. They have a name, a broken workflow, and a Slack channel to post the complaint in before lunch.
This is why institutions that genuinely want to prune something often can't bring themselves to do it in one motion. They split the act in half: mark for deletion now, actually delete later, after a grace period long enough that nobody can point to a single moment where they lost something specific. The gap isn't generosity. It's an admission that immediate removal creates an immediate, identifiable victim, and a delayed one doesn't, even though the outcome is identical.
None of this requires anyone in the system to want growth. Nobody on the team wants three API versions live at once. Nobody wants a tax code with four hundred credits nobody remembers voting for, or an org chart with titles that map to nothing. The growth isn't the goal. It's just the only move that clears the room without anyone in it having to lose, publicly, something they can name.
Which means the usual diagnosis, that organizations accrete complexity because people are lazy or because incentives reward building over maintaining, is only half right. People build because building is free of objection. They don't prune because pruning requires finding every person with a claim on the old path and getting each of them to agree to lose it in front of everyone else. Addition needs zero consents. Subtraction needs all of them.
Every codebase that's been alive more than a few years has a function somewhere with a comment above it that reads do not remove, legacy client depends on this, and nothing else. No ticket number, no name, no explanation of which client or why. The person who could have defended keeping it is long gone. The function survives anyway, not because anyone still believes it's necessary, but because nobody currently employed has the standing to argue it isn't.