Glossary
Technical debt
The deferred effort from earlier shortcuts in code or architecture. It does not disappear, it simply falls due later and at a higher price.
The image of debt works because it makes you think about interest. The shortcut itself is usually cheap; what costs is every later change in that place. A team paying interest does not notice it on an invoice, it notices that a task which took two days two years ago now takes two weeks.
Not every debt is a mistake. Debt taken on deliberately in order to reach a market earlier is a legitimate decision, as long as somebody knows about it and a repayment date exists. The problem is unconscious debt: it grows out of time pressure, staff turnover and missing knowledge, and it is written down nowhere.
The reason the topic rarely gets a hearing is the missing translation. "The code is messy" is not an argument for somebody who decides about budgets. "Every new feature in this area takes three times as long as comparable work elsewhere" is one.
It becomes measurable through proxies: lead time from idea to production, share of time spent on fixing defects, frequency of incidents after a deployment, number of areas only one person can touch. None of these numbers measures debt directly; together they paint a picture that holds up.
The most expensive answer is the complete rebuild. It promises to repay all debt at once and overlooks the fact that the old system keeps living during construction, changes and builds new debt. Step by step replacement is slower on paper and faster in reality.
What works in practice is a fixed share of capacity that goes into maintenance without a case by case justification. If cleanup work has to be justified afresh every time, it does not happen, because it loses against every feature.
How you notice it
- Estimates for comparable tasks differ widely within one area.
- After deployments, incidents keep piling up in the same corner.
- Certain areas can only be touched by one person.
- Cleanup work has to be justified individually every time.
Not to be confused with
- Legacy code
- Code without tests that earns money. Technical debt is the effort sitting inside it. A system can be legacy and carry little debt, if it is stable and understood.
- Bad code
- A judgement about quality. Technical debt is an economic quantity: it only costs once work happens in that place. Bad code in an area nobody ever touches is cheap.
- Refactoring
- The repayment. Changes the structure without changing behaviour. Without tests beforehand it is not refactoring, it is a rewrite with an open outcome.
When it fits
- The area is changed regularly: that is where interest really accrues.
- Ahead of a larger project in the same corner of the system.
- When incidents after deployments pile up in one area.
When it does not
- In stable areas nobody touches. There the debt is interest free.
- In components that will be replaced in the foreseeable future anyway.
- As an end in itself with no link to an upcoming project: that is tidying up, not investment.
How to approach it
- Translate into business languageNot "messy" but lead time, defect rate, incident frequency, dependence on individuals. Those numbers move decisions, judgements about quality do not.
- Prioritize by change frequencyThe areas touched most often come first. A look at the version history shows them faster than any analysis.
- Secure first, then changeCharacterization tests pin down what the system does today. Without that net every piece of cleanup work is a risk with no way back.
- Agree a fixed share of capacityTen to twenty per cent, without a case by case justification. What has to be justified afresh every time does not take place.
- Write down deliberate debtWherever a shortcut is taken, the reason, the cost and the repayment date belong in a visible list. Unconscious debt is the expensive kind.
- Measure the effect afterwardsCollect the same metrics again after three months. Without that evidence the share of capacity gets cut at the next deadline crunch.
Frequently asked
How do you explain technical debt to management?
Through time and risk, not through code quality. "Changes in this area take three times as long as comparable work elsewhere, and two out of three incidents in recent months came from there." That is a statement you can base a prioritization on.
How much capacity should go into repayment?
Ten to twenty per cent as a permanent arrangement, without a case by case justification. What matters is making it continuous: special campaigns after an incident fizzle out, because afterwards it is back to features only until the next incident arrives.
Is a rebuild not sometimes cheaper?
Rarely, and almost never for the reason it is proposed. The old system keeps living during construction, changes and builds new debt, and the rebuild has to reproduce behaviour nobody knows in full. Step by step replacement is slower on paper and delivers parts into production from the first month.
Is all technical debt bad?
No. Debt taken on deliberately in order to be in the market earlier can be the right decision. It differs from the bad kind in three ways: somebody knows about it, it is written down, and there is a point in time at which it gets repaid.