Technical debt is the future cost of shortcuts and postponed upkeep in software. Like financial debt it carries interest, and the interest is paid as slower and riskier changes: each new feature or fix takes longer, and breaks more, than it would in a system that had been kept in good order.
Ward Cunningham coined the metaphor. It is useful because it lets people who do not write code reason about a problem they cannot see directly, and this guide is written for them: the owners and managers who pay for software and have to decide where the money goes.
How the comparison with debt works
Borrowing money lets you have something sooner, and you pay interest until the loan is repaid. Software works in a similar way. A team that skips a step to meet a date delivers the feature sooner, but the skipped step does not go away. Until someone goes back and does it, every piece of work that touches that part of the system costs a little extra.
The skipped work is the principal. The extra time on every later change is the interest. As with money, a modest amount taken on for a good reason is sensible. A large amount that nobody is keeping track of can end up absorbing most of what you spend on the system.
Examples of technical debt
None of these shows on the screen. All of them make change more expensive.
- No automated tests. Nobody can tell whether a change has broken something elsewhere without checking the whole system by hand.
- An out-of-support framework or database. An upgrade was put off, and security fixes have now stopped. SQL Server 2016, for example, reached the end of support on 14 July 2026. Our end-of-support dates cover other platforms.
- Copy-and-paste code. The same rule exists in six places, so a change to the rule has to be made six times, and it is easy to miss one.
- A manual release process. Putting a new version live depends on one person working through a list of steps, some of them from memory.
- Business rules buried in database triggers. Something happens automatically when a record is saved, and nobody reading the application code would know.
- One person who understands it. The knowledge is in somebody’s head and nowhere else. Strictly this is a staffing problem, but it behaves like debt: the cost is deferred, then arrives all at once when they leave.
Deliberate and accidental debt
Some debt is taken on knowingly. A team launching before a deadline might support a single currency, for example, knowing that a second will be needed next year. That is a reasonable trade, provided the shortcut is written down and there is a plan to return to it.
Most debt in older systems is accidental. Nobody decided to take it on. The team did not know a better approach at the time, or the business changed and the original design no longer fits, or the framework aged while everyone was busy with other things. Even well-written software acquires debt this way, because the platforms it depends on keep moving.
The difference matters when you come to deal with it. Deliberate debt is known and can be scheduled. Accidental debt has to be found first.
How to tell you have technical debt without reading code
You do not need to open the code to see the symptoms. Look for these.
- Small changes take weeks. Adding a field to a form or a column to a report should be a short job. If it never is, the system is charging interest.
- Fixes break other things. A repair in one area is followed by a fault somewhere that seems unrelated.
- Estimates carry large contingency. Developers who cannot predict what a change will disturb protect themselves with padding, or decline to estimate at all.
- Developers are reluctant to touch certain areas. There are parts of the system that people route around, and requests involving them are met with a sigh.
- Releases are rare and tense. New versions go out seldom, outside working hours, with everyone on standby.
One of these on its own proves little. Several together, getting worse from year to year, is the pattern. When they are joined by an out-of-support platform, the system has usually become what people call a legacy system.
How technical debt is paid down
Seldom by stopping all other work for a clean-up, and seldom by rewriting the system from scratch. Debt is normally reduced in small steps alongside the work the business wants done anyway.
Tests first
Before a fragile area is changed, automated checks are written around what it does today. They show at once if a later change alters that behaviour, and they are what make every other repair safe to attempt.
Start where change is most frequent
Debt in code that is changed every month charges interest every month. Debt in code that nobody has touched for years costs nothing until someone has to touch it. The first repairs should go where the work is.
Improve each area as you pass through it
When a new feature takes the team into a poor part of the code, they leave that part a little better than they found it. Many teams also set aside a regular share of their time for upkeep, so that it is not squeezed out by feature requests.
Put platform upgrades on a schedule
Vendor support dates are published years ahead. An upgrade planned a year in advance is an ordinary project. One done in a hurry after support has ended costs more.
Where the debt is concentrated in a few large parts of the system, such as an old database or user interface, those parts can be replaced one at a time. We describe that approach under legacy software modernisation.
Whichever route you take, ask whoever looks after the system for a written list of the debt, ordered by what it is costing you. A list turns a vague worry into a set of decisions.
When it is fine to leave it alone
Not all debt is worth repaying. It is reasonable to leave it where:
- the system will be retired within a year or two;
- the code in question is stable and seldom changed;
- the shortcut was taken to test an idea that may not survive;
- the repair would cost more than the interest over the system’s remaining life.
The exception is security. An out-of-support component carries the same risk whether or not anyone is changing the code around it.
How we can help
We maintain and modernise business software, including systems built by other people, and reducing debt gradually is part of ordinary software maintenance. If you want to know how much debt a system is carrying before deciding what to do, our code audit gives you a written assessment at a fixed price.