The two pieces before this one described two kinds of accumulation: code nobody can prove is unused, and features that are used just enough to be indefensible to remove. Both share a structural cause worth naming directly. Everything that gets added has an advocate — someone wanted it, argued for it, and is accountable for whether it shipped. Removal has no equivalent. There’s no role whose success is measured in things that are gone, so removal happens only when someone volunteers, in the gaps between work that’s actually assigned.

That asymmetry is enough to explain the drift on its own. It doesn’t require anyone to be careless or short-sighted; it just requires that adding is a rewarded act and removing is a discretionary one. Over a few years of ordinary good work by reasonable people, you get a system with more surface than purpose — and nobody made a bad decision along the way, which is precisely why nobody can point at the moment it went wrong.

The fixes that work are small and structural rather than cultural, because “we should be better about cleanup” has approximately no effect. Attaching an expiry to things that are inherently temporary — flags, migrations, compatibility shims — turns the default from permanent to scheduled. Putting removal candidates in the same queue as feature work makes them visible to whoever prioritizes rather than dependent on someone’s spare afternoon. Making a change’s cleanup step part of the change itself, rather than a follow-up ticket, means the person with the most context does it while they still have that context. None of these are heroic; they just move deletion from something you have to remember into something the process already carries.

It also helps to notice when the moment is cheapest. The best time to remove a compatibility shim is immediately after the last caller migrates, when it’s obvious and small. The best time to delete a flag is the week the rollout finishes. Wait a quarter and the same work requires re-deriving why the thing exists, which is a different and much larger task — the same asymmetry that runs through this whole blog, where capturing context is cheap while you have it and expensive once it’s gone.

The thread’s point isn’t that lean systems are virtuous. It’s that a system’s weight is the sum of decisions nobody made — every deferred cleanup, every feature kept because removing it required a conversation, every branch left because proving it dead required work no one was assigned. Adding will always have advocates. Removing needs the process to advocate for it, because nobody’s performance review is going to.