Technical debt
Technical debt is the accumulated cost of shortcuts taken in software, where a quick solution was chosen over a sound one. Like financial debt it carries interest: every later change to the affected code takes longer and carries more risk than it would have done otherwise.
Also known as: Tech debt, Code debt, Design debt
Last reviewed
Why technical debt matters
It is the reason a system that shipped quickly gets slower to change every year. Each shortcut is individually reasonable, and each one makes the next change slightly harder, until a two-day feature takes three weeks and nobody can explain why to the board.
The useful part of the metaphor is the interest. Debt itself is not a problem — deliberately taking a shortcut to hit a launch date is often correct. The problem is never paying it down, because the cost is not a one-off; it is charged on every subsequent change to that code, indefinitely.
How technical debt accumulates
It arrives from four directions. Deliberate shortcuts taken to meet a deadline, which are legitimate if recorded and repaid. Decay, where a design that fitted the original requirements no longer fits what the product became. Dependency drift, as libraries, frameworks and platforms move on and the version you are pinned to falls out of support. And absent knowledge, where the people who understood a decision have left and nobody dares change the code.
The most expensive variety is usually the second. Nobody did anything wrong; the business simply changed around software built for an earlier version of it, and a proof of concept kept as a production foundation is the classic example.
Technical debt vs a bug
A bug is behaviour that is wrong. Technical debt is behaviour that is correct but structured in a way that makes future change expensive. Users see bugs; they never see debt directly, which is precisely why it goes unfunded.
That invisibility is the management problem. A bug has an obvious owner and an obvious fix, while debt only shows up as a gradual slowing of delivery that gets attributed to the team rather than the codebase. The way to make it visible is to express it in delivery terms — this area takes three times longer to change than the rest — rather than in technical language nobody outside the team can price.
When to deal with it
Not all of it, and not all at once. Repay debt in the parts of the system you are actively changing, where the interest is actually being charged; debt in stable code nobody touches costs very little and rebuilding it is usually a poor investment.
The signals that it has become urgent are commercial rather than technical: estimates growing for similar work, a rising share of time spent on unplanned fixes, dependencies out of support, or a reluctance to touch a specific area. If you have inherited a codebase and cannot tell how bad it is, a technical due diligence review answers that for a fixed fee before you commit to any plan.
Technical debt: common questions
No. Deliberately taking a shortcut to hit a launch date is often the right commercial call, and the metaphor works because borrowing can be sensible. The failure is never repaying it, since the cost is charged on every later change to that code rather than once.
In delivery terms rather than technical ones. Say that changes in this area take three times longer than elsewhere, and that the gap widens. Users never see debt directly, which is why it goes unfunded — making the cost visible as slower delivery is what gets it prioritised.
Rarely as a first move. Repay debt where you are actively making changes, because that is where the interest is charged, and leave stable code alone. A full rewrite replaces a known set of problems with an unknown one, and usually takes far longer than estimated.
Want to talk about your project?
Tell us what you’re trying to achieve and we’ll map the fastest credible path.