You Have to Give to Take

I've never met anyone who argues against cleaning up a product. Everyone agrees it's a good idea. It just never actually happens.

And I don't think that's a willpower thing. I think it's about where removing stuff sits in the process, and once you look at that, the outcome is kind of predictable.

Why removal never wins the argument

Here's what happens. Removing something gets treated as a project, so it goes into the backlog like any other project, and then it has to compete with everything else in there. In practice that means a cleanup ends up in the same planning meeting as a feature a specific customer asked for by name, and somebody in that meeting is keeping a tally of what shipped this quarter.

The cleanup loses. Every time. And it's not because anyone sat down, weighed the two, and decided the feature mattered more. It's because the feature shows up with a customer's name and a date attached, and the cleanup shows up with neither.

So the product only ever grows. Nobody decided that. It just falls out of how the meeting works.

Equivalent exchange

Fullmetal Alchemist opens with its first law:

To obtain, something of equal value must be lost.

When people apply this to software, they usually read it as "for every feature you add, remove one feature." That's not a rule anyone can actually follow, and it's not what the line says anyway. It says equal value, not equal objects.

The point I'd make is that you already made the trade. The moment you shipped the feature, you started paying for it. It's one more thing everyone has to keep in their head. It's another path that runs through every test run. It's another case to handle in whatever you build next, and one more thing that has to keep working while you change something else nearby.

And I want to be clear that this isn't technical debt. Technical debt is the shortcuts you'd go back and fix if someone gave you a free week. This is different. This bill comes from good features, built properly, that nobody regrets shipping. There's nothing to go back and fix. You just own more product than you did before, and owning more product costs more.

The thing you bought has a name, the price doesn't

Everything on the "take" side of the trade is easy to point at. There's the feature. There's the customer who said yes. There's the line in the changelog and the demo that went well.

Nothing on the "give" side is like that. What you gave up is speed, stability, how long it takes a new hire to get productive, and how confident anyone feels changing the code next quarter. Nobody demos those things, so they get spent quietly. And the first time anyone notices is a year later, when shipping a small change somehow takes a month and nobody can explain why.

Ask the people who'll pay for it

Most of the time you can't put a real number on this. The cost shows up months later as work that nobody traces back to the feature that caused it, so any number you write in an approval doc is basically made up. What actually works is cruder than that. You ask the engineers who are going to carry the thing, and then you believe what they tell you. "This one's fine" and "this one is going to slow us down for a year" is the most accurate pricing you're going to get, and the only people who have it are the ones who'll be maintaining the feature.

So it's a trust problem more than a process problem. If you ask and the answer never changes what ships, you weren't really asking. You were just letting people vent before the decision that was already made.

And if nobody ever says what a feature costs, you're not choosing to build it. You're just building it.