The Shape of the System

The Courage to Delete

Every other material gets lighter when you take something away. Software is the one that fights you for the privilege.

retiring planning

There is a small experiment I think about more than is reasonable. Some researchers sat people down in front of a wobbly little structure made of toy bricks - a figurine on a platform, with a roof over it that needed steadying - and they offered a reward for making the thing stable, but with a small penalty for every brick you added. There was an obvious fix sitting in plain sight. One pillar held the platform up too high, and if you pulled that one pillar the roof just settled flat. Taking it away was the best move and it was free, and most people never saw it. In the plain version of the task only about four in ten thought to take anything away at all. Then the experimenters changed one thing. They added a throwaway line to the instructions saying that removing pieces was allowed and cost nothing, which had been true the whole time anyway, and the number of people who solved it by subtracting jumped by half again. This is real work, published in Nature in 2021, and one of the authors, Leidy Klotz, went on to write a whole book about it.

The bias isn't stupidity. It's a default. The first idea that turns up is to add something. Taking away is the one you have to go and fetch. And out of all the materials a person can shape, software is the one where this instinct does the most damage, because the thing you add doesn't just sit there being slightly too much. It asks to be maintained and tested and shipped, and carried around in some tired head forever after.

Bricks, clay, prose, a garden - take something away and the thing gets lighter and simpler and easier to hold in one hand. Software goes the other way. A line you delete costs nothing to run. But a line you keep is a standing debt. It has to be read by everyone who passes it, and kept working as everything around it moves, and tested, and deployed, and woken for at bad hours, and held in the head of whoever next changes the thing next to it. Every feature is a small permanent tax and the tax pays for nothing.

This is less a personal failing than a law. Meir Lehman spent years watching real systems and noticed that a useful one has to keep changing or it slides into irrelevance, and that each change tends to make it more tangled unless somebody spends real effort pushing the tangle back. Leave it alone and software doesn't hold still and it doesn't simplify either. It accretes. Some of the weight you can't avoid - that's the true difficulty of the problem you're actually solving, what Fred Brooks called essential complexity. The rest is the complexity you bolted on yourself: the fourth way to configure the same thing, the abstraction built for a future that never turned up. Only that second kind is yours to delete, but there's an enormous amount of it, and it's load-bearing in nobody's life.

Don't believe the comfortable story that unused code is harmless because it never runs. Dead code isn't a museum piece. It's a loaded gun in a drawer. The gentle version is a configuration flag added "temporarily" so that one big customer could opt out of a redesign. The customer leaves, the flag stays, and years later every new feature still has to be built and tested in both of its states, which doubles the work for a branch no living user takes. The violent version brought down a rocket. On the fourth of June 1996 the first Ariane 5 lifted off, and barely forty seconds later it had torn itself apart, taking four scientific satellites with it that had taken years to build. The cause was a small piece of software that had no business running at all. It was an alignment routine carried over wholesale from the older Ariane 4, where it earned its keep in the last seconds before launch. On the Ariane 5 it did nothing useful once the rocket left the pad, but it had been left running anyway. About half a minute into the flight the new rocket's much greater horizontal speed produced a number too big for that old code to hold. The conversion overflowed, the guidance system shut down, and the backup was running the very same code and had already failed the very same way a fraction of a second earlier. Nobody had decided to run that routine. It was just still there. The danger was never about what dead code does while it sits there. What gets you is that it stays, waiting for the one input that wakes it up.

The reason people won't delete is fear, and the fear is reasonable - what if we need it back. The answer isn't courage conjured out of nowhere. It's reversibility built on purpose. Jeff Bezos once split decisions into two kinds. There's the one-way door you can't walk back through, which deserves all of your caution, and there's the two-way door you can, which you should go through quickly because coming back is cheap. Most engineering decisions are two-way doors that we treat as one-way out of habit, and so we hoard. The craft is in making the doors swing. Put the thing you might remove behind a flag, or behind some seam, or behind a rollback so boring that undoing it is a non-event. Cheap reversal is what buys you the nerve to subtract, because you're no longer betting the whole building on being right.

The experiment with the bricks already handed us the cure. People did the right thing the moment somebody made removal visible, so build that reminder into the work itself. A merged change that comes out net-negative on lines and loses no behaviour is a good week's work. Ask of every ticket whether its best version deletes something. Keep a standing list of things to kill, and then go and kill them. The bravest change you can make takes the codebase backwards in size, and it leaves the thing clearer than it was, and almost nobody gets thanked for that, which is why it's rare and why it's worth so much. The engineer who spends a fortnight removing four thousand lines of a feature nobody uses ships nothing you can point at on a screen, and quietly makes the next five things everyone builds easier. People will call that a slow week. It isn't. It's the job.

In the manifesto, this is tenets (XX) and (XXI).

Sources

One of a series of field notes on building software for the way minds actually work: tired, distractible, ordinary, and now partly machine. They all lead back to the manifesto behind them, The Shape of the System.