Technical Debt: What It Is, How to Measure It and When to Act

Technical debt is the future cost of the shortcuts taken today in software development: code written in a hurry, missing tests, dependencies that were never updated, architectures designed for a smaller company than the one you run now. Like financial debt, it buys time immediately and charges interest later: every change costs more work and carries more risk, until someone decides to pay it back. If you need to know how much debt your system carries, and where, that is the job of a technical due diligence of the software.

This guide explains where technical debt comes from, which signals let a CTO or a business owner measure it without reading code, what ignoring it costs according to the public studies available, and when it makes sense to bring in someone from outside.

In short

• The term dates from 1992 and Ward Cunningham: code that is "not quite right" is a debt, and every minute spent working around it is interest paid.
• Not all technical debt is a mistake: debt taken on deliberately, to reach the market sooner, is a choice. The problem is the debt nobody records and nobody repays.
• It is measured through delivery signals (release speed and stability), code signals (tests, dependencies, fragile areas) and organisational signals (unplanned work, dependence on a few people).
• In McKinsey's 2020 survey, CIOs estimated that 10–20% of the technology budget for new products went to resolving technical debt problems.
• Incremental refactoring and a full rewrite are two different ways of paying it off: the choice is made on evidence, not on the age of the code.

What is technical debt?

Technical debt is the gap between how a piece of software is built today and how it should be built to change quickly and safely. Every time the fastest solution is chosen over the most solid one, time is borrowed from the future. The loan is repaid with interest: more frequent bugs, slower releases, developers who spend their days working out what the code does instead of improving it.

The metaphor comes from Ward Cunningham, who in 1992, presenting the WyCash system at the OOPSLA conference, wrote that shipping first-draft code is like going into debt: a little debt speeds development up, as long as it is repaid promptly with a rewrite; the danger comes when the debt is not repaid, because every minute spent on "not quite right" code counts as interest.

The metaphor works because it speaks the language of the business. A CFO does not need to know what a coupled module is to understand that an unrecorded debt, with an interest rate that keeps rising, is a risk that belongs on the balance sheet.

What types of technical debt are there?

The most useful way to classify it is still the quadrant Martin Fowler proposed in 2009, which crosses two questions: was the debt taken on deliberately or not? And prudently or recklessly?

The quadrant clears up a point that is often misunderstood: prudent, deliberate debt is normal in any product that has to reach the market. Inadvertent, prudent debt is unavoidable, because a team only really understands a problem after solving it once. The debt to avoid is the reckless kind, and above all the kind nobody ever wrote down.

In practice, debt accumulates in four areas:

• Code: duplication, enormous functions, business logic scattered everywhere, no automated tests.
• Architecture: components so tightly coupled that a change in one place breaks something elsewhere.
• Infrastructure and dependencies: libraries, frameworks, databases and operating systems that have reached end of support.
• Knowledge: missing documentation, and parts of the system only one person knows how to change.

Where does technical debt come from?

Technical debt rarely comes from incompetent developers. It comes from reasonable decisions taken under pressure and never revisited:

• Commercial deadlines that push the team to ship the first working version, with no time to tidy it up afterwards.
• Requirements that change faster than the architecture: the software stays designed for a business that no longer exists.
• Turnover in the team and among suppliers, with knowledge leaving together with the people.
• No automated tests, which turns every change into a gamble and discourages anyone who would like to improve the code.
• Postponed upgrades of libraries and platforms, until the version jump becomes a project in its own right.
• Code generated in a hurry, including with AI assistants, accepted without a senior review of tests, dependencies and security.

When these causes add up over years, the debt turns the software into a legacy system: still critical for the business, but harder and harder to change.

How do you measure technical debt?

There is no single number that measures technical debt, and you should distrust anyone who promises one. There are, however, concrete signals that a CTO, or a business owner with no technical background, can check within a few weeks. Taken together, they say how much debt there is and where.

Delivery signals. The delivery metrics from the DORA research programme are the most solid starting point, because they measure the effects of the debt rather than the debt itself:

• the time between a change to the code and its arrival in production;
• release frequency;
• the share of releases that need immediate remediation, such as a rollback or a hotfix;
• the time needed to restore service after a failed release;
• the share of unplanned releases, made only to fix a production incident.

If releases are slowing down and failing more often while the team stays the same, the debt is growing.

Code signals.

• Automated test coverage on the flows that bring in revenue or handle sensitive data, not the average percentage across the whole codebase.
• Dependencies, frameworks and database versions that are out of support or carry known vulnerabilities.
• "Hotspots": the files that change most often and are also the most complex. That is where the debt costs most, because the interest is paid on every change.
• Build time and the time it takes to start a development environment.

Static analysis tools such as SonarQube estimate the debt in working days, with methods derived from SQALE. They are useful for following a trend over time, less so for deciding: they do not know which parts of the code matter to the business.

Organisational signals.

• The share of each sprint spent on bugs and unplanned work.
• Parts of the system only one person knows how to change.
• The number of weeks a new developer needs before shipping their first change to production.
• Estimates that are always wrong in the same direction on the same areas of the system.

What does ignoring technical debt cost?

The cost of a specific system's technical debt can only be estimated by analysing it. Public studies do give the order of magnitude, though, and they are best quoted together with their scope:

These figures are not the cost of your software. But they say one consistent thing: technical debt does not stand still. The interest is paid in developer time, in budget taken away from new features and in operational risk, and it grows if nobody manages it. The UK case shows where that leads: when almost the whole budget goes to keeping existing systems alive, nothing is left to change them.

There is also a cost the tables do not capture: security. Components out of support no longer receive patches, and a system nobody dares to touch is also a system nobody updates.

Technical debt in Agile and Scrum: how to manage it in the backlog

In Agile teams, technical debt grows when it stays invisible: user stories have a product owner who defends them, debt items do not. Three practices bring it back under control:

• Record it in the backlog like any other work, with a description of the business impact, an estimate and an owner.
• Reserve a fixed share of every sprint for repayment, instead of hoping for a "technical sprint" that never comes.
• Put it in the Definition of Done: a feature is not finished if it leaves missing tests or outdated dependencies behind.

Priority goes to the debt in the areas that change most often and cause the most incidents, not to the code that looks ugliest. An old module that is stable and never touched can wait.

Refactoring or rewrite: how do you pay technical debt back?

There are two ways to pay technical debt back: refactoring, which improves the structure of the existing code without changing its behaviour, and rewriting, which replaces a component or the whole system.

• Incremental refactoring: the right route in most cases. Tests are added on the critical flows, then one part at a time is improved, starting with the hotspots. The business does not stop and every step is reversible.
• Progressive replacement (strangler fig): new features are built around the old system, behind stable interfaces, and responsibilities move across one at a time until the old component can be switched off.
• Full rewrite: worth it when the foundations can no longer carry the load, the technology is no longer supported or the business model has changed. It is also the riskiest option, because two systems have to be maintained for months.

The questions that decide between these options are in our framework on rewrite vs. refactor, written for the CTOs of mid-sized companies.

When should you call in a technical debt audit?

An external audit is needed when the debt has stopped being a topic for the engineering team and has become a topic for the business. The typical signs:

• every release brings incidents, and the team is afraid to touch some parts of the system;
• estimates for new features keep growing while the scope stays the same;
• a critical part of the system depends on one person, in-house or at a supplier;
• you have to decide whether to rewrite, and opinions inside the company are divided;
• you are about to acquire a company or a software product, or an investor is asking for the real state of the technology;
• regulations such as NIS2, or customer requirements, oblige you to show how you manage security and updates.

In these cases a technical due diligence of the production software says what is at risk, what it costs to fix and in what order, with a written report in two to four weeks. It is the way to turn technical debt from a feeling into a line in the budget: a list of issues ordered by business impact, with an effort estimate for each. In the Neotecnica case, for example, the code and security audit closed with more than 13,000 issues analysed and more than 19 vulnerabilities fixed.

If instead the debt has already passed the danger line, and the system breaks in production while the business has to keep using it, the next step is stabilising the legacy software: systematic repair of what breaks, tests on the critical flows and releases that become predictable again, without stopping operations.

Want to know how much technical debt your software carries, and where it makes sense to start paying it back? Write to us: you will talk to our engineering team, and we will tell you whether you need an audit, a stabilisation project, or whether your own team can handle it.

Contact our engineering team →

Sources

• Ward Cunningham, "The WyCash Portfolio Management System", OOPSLA '92 experience report (1992): c2.com
• Martin Fowler, "Technical Debt Quadrant", 14 October 2009: martinfowler.com
• McKinsey & Company, "Tech debt: Reclaiming tech equity", 6 October 2020 (accessed 7 October 2026): mckinsey.com
• Stripe, "The Developer Coefficient", September 2018 (accessed 7 October 2026): stripe.com
• CISQ, "The Cost of Poor Software Quality in the US: A 2022 Report", with the Synopsys press release of 6 December 2022 (accessed 7 October 2026): it-cisq.org
• UK Department for Science, Innovation and Technology, "State of digital government review", 21 January 2025: gov.uk
• DORA, "DORA's software delivery performance metrics", updated 5 January 2026 (accessed 7 October 2026): dora.dev