Deciding what to stop

A feature, once shipped, does not simply sit there quietly earning its keep. It asks, every so often, for a small portion of someone’s attention: an engineer who must remember it exists before touching code near it, a support team who must answer for it, a document that must stay accurate, a new hire who must learn it. None of this shows up in the moment of shipping. All of it shows afterwards, indefinitely.

Quality of a product is not the number of things it does. It is the value those things create, minus the complexity they impose in order to keep creating it. Many features that once cleared that bar quietly stop clearing it, not because anything broke, but because everything around them kept changing while they did not.

This suggests a perhaps slightly uncomfortable conclusion: shipping was never really a one way door. Most teams have a clear process for deciding what to build. Fewer have processes for deciding what to stop maintaining. Every retirement is not a small failure, something to be quietly apologised for. A team that never removes anything is not a team with an unusually good track record. It is a team that has not yet looked.

This is not an argument to romanticise removing things, only for weighing them honestly, with the same seriousness given to the decision to build them in the first place. A feature earned its place once, under conditions that no longer necessarily hold. Asking, periodically, whether it still does, seems to me not a failure of nerve but rather an unusually disciplined form of care.