Why Small Software Changes Become Expensive

A request lands that sounds trivial. Add a field to a form. Change a tax rule. Show a different message to one type of customer. Everyone expects it to take an afternoon. Three weeks later it is still in progress, two other things have broken in the meantime, and the bill is far larger than the size of the change could possibly justify. The frustrating part is that nobody is being lazy or incompetent. The change really was small. The system around it was not ready to receive it.

This is one of the most common — and most demoralising — symptoms of an ageing application. It is worth understanding precisely, because the instinct it provokes is usually the wrong one. When small changes hurt, the temptation is to conclude that the whole system is rotten and must be replaced. Far more often, the cost is concentrated in a few specific places and can be reduced without a rebuild. To do that, you first have to know why the cost is there at all.

The four things that make a small change ripple

When a change costs far more than its size, the cause is usually some combination of four conditions. They tend to travel together, and each one amplifies the others.

• Coupling — the parts of the system are tangled together, so touching one thing forces you to touch many. The form you are editing reads from the same place that three reports and a nightly export also read from, and none of them agreed to your change.
• Missing tests — there is no automated way to prove the change did what you intended and nothing else. So every edit is a bet, checked by hand, slowly, and never quite completely.
• An ageing framework — the technology underneath is old enough that few people still work with it comfortably, upgrades are risky, and the modern shortcuts everyone else uses are simply not available.
• One-person knowledge — the reasons the system works the way it does live in one person’s head (or in a supplier who has moved on), not in anything written down. Change waits for them, and stops when they are away.

Coupling is the one that turns a small change into a large one. Michael Feathers, who wrote the standard book on working with old code, gives the cleanest definition of the underlying problem: legacy code is simply code without tests. “If you have code and it has lots of tests it’s relatively easy to change. If you don’t have the tests, you’re really in serious trouble,” he puts it. Without that net, you cannot make a change quickly, because the only way to know whether you have broken something is to ship it and wait for the complaint.

Legacy code is code without tests. If you have code and it has lots of tests it’s relatively easy to change. If you don’t have the tests, you’re really in serious trouble.

The ageing framework and the one-person knowledge then make everything slower and more frightening. An old framework means upgrades are deferred year after year — “we’ll do it later” — until later becomes a forced, urgent scramble. And when the reasoning lives in one head, every change funnels through a single bottleneck, and that person’s holiday becomes a business risk. None of these is dramatic on its own. Together they are why a trivial request quietly consumes a month.

Why it gets worse on its own

There is a reason this tends to compound rather than hold steady. Software that keeps being used keeps being changed, and unless someone is actively keeping it in shape, each change tends to add a little more tangle than it removes. The system grows more complex simply by being maintained. This is not bad luck; it is the normal physics of living software, first described decades ago. Left alone, the cost of the next change is always a little higher than the last.

That is also why a fragile system feels like it is getting more expensive precisely as it becomes more important to the business. The more the business relies on it, the more change it asks for, the faster the tangle accumulates — and the more nervous everyone becomes about touching it. Fear of change is a rational response to a system you cannot prove is safe. It is also extremely expensive, because it converts a maintenance problem into a strategic one: you stop being able to respond to your own customers.

You don’t have to fix all of it

Here is the part that changes the economics, and the part most owners are never told: the cost is not spread evenly across the system. The overwhelming majority of any codebase is stable — written once, rarely touched again. The pain concentrates in a small number of places that are both complicated and changed often. Adam Tornhill, who studies this by mining the actual change history of real systems, calls these places hotspots, and his finding is blunt: “all code really isn’t equal.” Refactoring code nobody ever changes produces nothing. Fixing the few places where complexity meets frequent change is where the return lives.

All code really isn’t equal. A hotspot is a signal of relevance — if it’s a hotspot it means it’s very likely that we will continue to work with that part of the code.

This is genuinely good news, because it means the fix is targeted, not total. You do not have to rebuild the system to make change cheap again. You have to find the handful of places that are costing you the most and bring those back under control — and you can find them with evidence, by looking at where change actually lands, rather than by guessing from what looks untidy.

How to bring the cost back down

The sequence that works is consistent across systems, and it is deliberately unglamorous. Safety first, then speed.

• Find the hotspots. Use the change history to identify the few areas that are both complex and frequently touched. That is where the money is leaking.
• Add a safety net there first. Put automated tests around the risky areas so a change can be proven safe in seconds rather than feared for days. For old code this usually means characterisation tests — tests that simply capture what the system does today, so you can change it without silently altering behaviour.
• Untangle the worst coupling. With the net in place, separate the parts that force every change to touch everything, in small reviewable steps, never a stop-the-world rewrite.
• Write down the hidden knowledge. Turn the reasoning in one person’s head into documentation a new developer can rely on, and reduce the single-person dependency.
• Make releases routine. A slow, manual, nerve-wracking release process adds its own tax to every change. Making releases boring is one of the cheapest wins available.

This is also where modern AI tooling genuinely helps — though as method, not magic. AI is strong at the slow, expensive comprehension work: reading an undocumented area and explaining what it appears to do, drafting the first version of the tests that pin current behaviour, surfacing the hidden connections between files. We use it to do the labour faster. We do not let it decide what is correct. Every generated test and change is reviewed by an engineer, because an AI will happily write a test that confirms an existing bug as if it were intended behaviour. The discipline is the point: AI accelerates the work; humans keep the judgement.

If small changes have started to cost more than they should, the most useful thing you can do is find out where the cost is actually concentrated before spending a penny fixing it. Our free software assessment at /application-modernisation/free-assessment does exactly that: it identifies the few areas driving most of the cost and risk, and gives you a prioritised, plain-English plan for bringing the cost of change back down — fix, not rebuild, wherever that is the honest answer.