Why maintain software you could just rebuild?

A client asked us last month why we were spending two days patching a bug in a tool that took eleven minutes to build in the first place. Good question. We didn't have a good answer.

We maintain software because building it used to be expensive. That's the whole logic of maintenance: the original build cost real money and real time, so when something breaks, the rational move is to repair it rather than start again. Refactoring, patching, careful incremental change all assume the alternative, rebuilding from scratch, is worse.

That assumption is quietly dying. For a widening class of software, the cost of producing a working version has fallen close to zero. Not cheaper than it was. Close to free, and falling further. If that trend keeps going, the maintenance calculation doesn't just get a bit more favourable to rebuilding; it inverts completely.

Follow it through

Take the logic seriously and it leads somewhere uncomfortable: if rebuilding is reliably cheaper than fixing, the disciplined thing to do stops being "maintain" and starts being "regenerate." Every time a system gets messy, throw it away and build a clean one. No refactor, no careful archaeology of somebody else's decisions from eight months ago. Just describe what the thing needs to do, and make a new one that does it.

Run with that and the job that matters most isn't writing code any more. It's describing, precisely, what the software is for. The code becomes disposable. The specification doesn't. That's the actual shift: not "developers become unnecessary" but "the valuable skill moves from writing and maintaining code to writing and maintaining an accurate description of what the system needs to do." Keep that description current and correct, and rebuilding is just execution, cheap and repeatable. Let it drift, and you're rebuilding the wrong thing quickly instead of the right thing slowly.

What doesn't regenerate

Not everything follows the logic cleanly, and a thought experiment that pretends otherwise isn't honest. Data doesn't regenerate. A customer mid-transaction doesn't regenerate. A production integration another business depends on doesn't regenerate. Those things anchor a system to continuity in a way code never had to. But notice what that anchor actually is: it's never the code itself. Nobody has ever needed to keep a specific file of source intact for its own sake. What has to survive is the data and the promises made to the people using it. The code was always replaceable in principle; it's only now becoming replaceable in practice.

The bit worth taking seriously

If this holds, the asset you've been protecting by maintaining your software was never the software. It was the specification — the accumulated, precise understanding of what the thing is supposed to do, sitting mostly in people's heads and half-written commit messages. If code keeps getting cheaper to produce, that's the part worth investing your time in properly: writing it down, keeping it current, treating it like the thing you'd actually be sorry to lose. Because increasingly, it's the only part that doesn't regenerate on its own.

If your team's real expertise is trapped in people's heads instead of on paper, book a session and we'll help you get it down before you need it.