Why does every small fix seem to take longer than the last one?
If you run a business whose key application frustrates its staff or customers — the quoting tool, the booking system, the internal platform everyone curses — you have probably noticed the pattern. A change that should take a day takes a week. A simple fix breaks something unrelated. The developer starts using a phrase you half-suspect is an excuse: "technical debt". This article explains what that phrase means in business terms, why it behaves like a loan, and what paying it back looks like.
Debt is a business decision, not a developer excuse
Technical debt is what accumulates when a system is built or changed under time or budget pressure, and the shortcuts taken to hit the deadline are never revisited. The shortcuts are real and rational — the deadline mattered, the trade was worth making at the time. Debt forms when nobody records the trade and schedules the repayment. It takes a few recognisable forms:
- Shortcuts in the code. Quick fixes that work but do not fit the system's structure.
- Outdated dependencies. Components the system relies on that are no longer maintained, or versions behind — each gap making updates harder and riskier.
- Missing tests. No safety net verifying that changes do not break existing behaviour, so every change carries fear.
- Knowledge concentrated in one person. The system exists partly in code and partly in someone's head — a single point of failure.
How the loan compounds
The loan metaphor is precise, because debt in software behaves like debt in finance. The principal is the set of shortcuts. The interest is what you pay continuously: every change takes longer because the system is harder to understand and riskier to touch; every bug fix must navigate workarounds. Interest also rises with time, because the people who understood the shortcuts leave, and the components they depend on age further out of support.
The compounding is why the pattern feels sudden to owners. For years the interest is invisible — the original developer is still around, changes are manageable. Then the developer leaves, or a component reaches end of support, and the interest bill arrives all at once. It was accruing the whole time; the statement just never came.
Illustrative example: a distribution firm runs its operations on an internal application built over a decade. Year after year, quick fixes landed under deadline pressure, none recorded as debt. The original developer left two years ago; the replacement, competent and honest, now quotes a week for changes that once took a day — not because the new developer is slower, but because every change must be investigated rather than understood, and tested by hand rather than by suite. A component the system depends on is approaching end of support, raising the stakes on everything. The debt was not created by the departure. The departure merely presented the bill.
Why the big-bang rewrite usually fails
The natural owner response to a big debt statement is the rewrite: scrap it, rebuild it properly. The instinct is understandable and the track record is poor. Rewrites fail predictably, for reasons that have nothing to do with competence:
- The old system keeps the business running while the new one is built — so the old one must also be maintained, often far longer than planned, doubling the cost.
- The undocumented knowledge lives in the old system. The rewrite discovers, late and expensively, what the old system actually did — including the odd behaviours that turned out to be load-bearing.
- Scope expands to match ambition. "While we're rebuilding it" pulls in every wish ever had, and the new system chases a moving target.
None of this means rewrites never happen. The honest sequence simply starts elsewhere.
Paying it down incrementally
The workable path is the one lenders would recognise: service the loan steadily rather than defaulting into a rebuild. In practice:
- Stabilise first. Establish the basics that make change safe: automated tests around the parts that change most, repeatable deployment, monitoring that shows when something breaks.
- Pay a little principal each change. When a feature touches a messy area, budget a margin to tidy that area properly — not the whole system, just the part being touched. Debt shrinks where work happens.
- Record deliberate shortcuts as debt. When a deadline forces a shortcut, write it down with a repayment note. Debt you can see is debt you can schedule.
- Spread the knowledge. Pair the people who know the system with people who do not — the single most effective interest-reduction available, and it is cheap.
Constraints and trade-offs
Two honest caveats, so debt talk stays honest:
- Not all debt is bad. Deliberate shortcuts to hit a market window or a regulatory deadline can be exactly right — a business loan taken for a business reason. The failure mode is not borrowing; it is borrowing invisibly.
- Purity is not the goal. A system with zero debt would have spent its history polishing rather than serving customers. The trade-off is visibility and discipline: debt that is recorded, budgeted and serviced is a tool; debt that is unrecorded is a trap.
Your action checklist
- Ask, without accusation, where the system has shortcuts nobody revisited.
- Check whether the system has automated tests, and whether anyone runs them before changes.
- List the components approaching end of support, with dates.
- Ask who besides one person can make a safe change today.
- Record the next deadline-forced shortcut as named debt with a repayment note.
- Choose one frequently-changed area and service its debt this quarter.
If your key application bills you interest every time it changes, our web application maintenance service provides the rhythm that reverses it: stabilise, then service the principal steadily — tests, updates and shared knowledge, in measured increments. And if you want the honest size of the loan first, our technical review examines the codebase and its dependencies, and tells you what the interest costs.