Technical debt: definition, warning signs and a plan to reduce it

Each change takes longer than the last, one fix breaks something else, and the team hesitates to touch parts of the application: this is often technical debt making itself felt. This guide explains what the term covers, how to spot it from management level and how to reduce it without stopping everything else.

It is aimed at executives, IT directors and founders who hear about technical debt from their teams or their provider, and want to know whether it is serious, what it costs and what to decide.

Technical debt: definition

The expression comes from Ward Cunningham, one of the pioneers of agile development. In 1992, in an experience report presented at the OOPSLA conference, he compared shipping first-time code to taking on a loan: a little debt speeds development, as long as it is paid back promptly with a rewrite. The danger lies in debt that is not repaid: every minute spent on not-quite-right code counts as interest.

For a company, the useful definition is simple: technical debt is the gap between the application as it is and what it should be in order to evolve without needless effort. The principal is the postponed work. The interest is the time lost every time someone works in an affected part.

So it is not a synonym for “bug” or “bad code”. An application can work perfectly for its users and carry heavy debt: it is paid when the application has to change, not when it is used.

The four kinds of technical debt

In 2009, Martin Fowler proposed a grid that has become a classic: debt is deliberate or inadvertent, and prudent or reckless. For him, the useful question is not whether there is debt, but what kind.

Based on Martin Fowler’s “Technical Debt Quadrant” (2009).

Only the prudent, deliberate box is a management choice: the debt is known, recorded and dated. The reckless, inadvertent box is the most expensive, because nobody knows where it is or how much it weighs. It is often what you find when taking over an application built quickly by successive contributors (see our method for taking over a web application).

Where it hides in an application

• The code. Overlong functions, logic copied in several places, names that do not say what they do.
• The architecture. Parts so tightly bound together that one cannot change without touching the others.
• Dependencies. A language, framework or library whose version no longer receives fixes. PHP 8.2, for example, now only receives security fixes, until 31 December 2026 (see our article on the end of PHP 8.2 support).
• Tests. Few or no automated tests: every change is checked by hand, or not at all.
• Deployment. A manual, lengthy release that only one person knows how to do.
• Documentation and knowledge. Business rules written down nowhere except in one developer’s memory.

The signs visible from management

An executive does not read the code. But they do see the symptoms, which come back almost every time.

• Lead times lengthen for the same requests, and estimates become unpredictable.
• One fix causes another problem elsewhere: regressions multiply.
• The team avoids certain parts of the application, or says “it should all be rewritten”.
• Releases are rare, bundled and dreaded.
• Only one person knows how to do certain things, and their absence blocks the rest.
• A language or framework version is no longer maintained, and the upgrade keeps being postponed.
• A new developer takes weeks to become autonomous.

Two or three of these signs are enough to justify a review of the current state. None of them, on its own, says how much the debt weighs: that is the job of the inventory.

What it really costs

The figures that circulate on the cost of technical debt mostly come from vendors or consultancies selling the cure: we quote none of them. The real cost is measured in your own application, and it takes four forms.

• Time. The interest: every change in an indebted part costs more days than it should. It is the most visible cost, and it grows over time.
• Risk. A component that no longer receives fixes stays exposed to vulnerabilities discovered after its end of support. For software publishers, the Cyber Resilience Act tightens obligations on this point.
• Dependence. When knowledge rests with one person or one provider, changing becomes slow and costly.
• Missed opportunities. Time spent working around the debt is not spent on the changes that matter to the business.

Reducing technical debt in five steps

1. Take inventory. List what weighs, part by part: dependencies and their end-of-support dates, test coverage, how releases are done, the areas the team dreads, what is not documented. An outside view helps, because the team in place has grown used to its workarounds: that is the purpose of an audit of the existing application.

2. Estimate and rank. For each item, an estimate in days of the repayment, and two questions: what risk does it carry, and how often does anyone work in that part? Heavy debt in a module nobody touches can wait. Light debt in the module changed every week costs interest every day.

3. Reserve time, regularly. A fixed share of the team’s capacity, every cycle, goes to repayment. That share is decided with management, just like new features: it is what protects tomorrow’s speed. In a maintenance contract, it is written down in black and white (see our guide to evolutive maintenance).

4. Repay where you work. The most cost-effective approach is to clean up a part when a change touches it: it is already understood, already being tested. Security updates, however, are never postponed.

5. Stop creating more. Automated tests on what changes, a review of every change by a second developer, dependencies kept up to date, and a shared definition of “done” that includes documentation. When the team chooses to take a shortcut, it records it, with the date it will come back to it.

Repay gradually or rebuild

“It should all be rewritten” is often the first reaction to an indebted application. Yet a full rebuild halts new features for months, recreates defects already fixed in the old version and carries its own risk of debt. Gradual repayment is the default path; a rebuild is justified in a few cases:

• the underlying technology is no longer maintained and no reasonable migration exists;
• the business has changed so much that the application no longer fits the need;
• the inventory shows that almost every part would have to be redone.

Even then, rebuilding piece by piece, part by part, while keeping the old application running, limits the risk. The decision is made on the inventory, not on an impression.

Frequently asked questions

Debt can be managed

Technical debt is neither a fault to hunt down nor a fate to accept. It is a liability, to be listed, costed and repaid at a pace you decide, like any other. What makes it dangerous is ignoring it.

iones’ French-speaking nearshore team, based in Tunis, takes over existing applications under application maintenance, with time set aside for repaying debt, and can start with an audit of what you have. You can also write to us for a first discussion.