Technical debt: what it costs and how to control it

March 12, 2025

Key takeaways

Technical debt is a liability, not a moral failing: it is the gap between how software is built and how it would need to be built to change easily, and it charges interest as slower delivery and higher risk.
The costs are documented: McKinsey found 30 percent of surveyed CIOs believed over 20 percent of their new-product budget was diverted to tech debt, and Stripe estimated developers lose more than 17 hours a week to maintenance.
Debt loses every individual prioritisation call while making all of them more expensive — IDC found CIOs aware of the cost still rank it below AI and cybersecurity.
Measure with two layers: a tracked code metric like SonarQube’s Technical Debt Ratio, plus a plain debt register the business can read.
Pay down continuously — a protected slice of each cycle, prioritised by interest rate and risk, focusing on dependencies and code discoverability as DORA recommends.

Every leader running software has felt the same slow change without quite naming it. A request that used to take a week now takes a month. A small change in one place breaks something unrelated. New engineers take longer to become useful, and the team spends more of its time keeping the lights on than building anything new. The software still works, more or less, but it has become expensive to change — and the cost is mostly invisible until you try to plan around it.

That drag has a name. Technical debt is the gap between how the software is built today and how it would need to be built to change easily. It is not the same as bad work, and treating it as a moral failing is the fastest way to stop people talking about it honestly. The more useful framing is financial: debt is a liability you take on, sometimes deliberately and sensibly, that charges interest until you pay it down.

Where the metaphor comes from

The term was coined by the programmer Ward Cunningham in a 1992 experience report at the OOPSLA conference, describing a financial software system. According to Cunningham, shipping first-time code is like going into debt: a little debt speeds development, so long as it is paid back promptly with a rewrite. He later clarified, as recorded in the Wikipedia summary of the metaphor, that he meant shipping code that reflects your current understanding of the problem and then refactoring as that understanding grows — not a licence to write messy code on purpose.

That distinction matters for a business audience, because the two get confused. Some debt is the honest cost of moving quickly while you are still learning what the business actually needs. Some is accidental — the result of rushed corners, staff turnover, or a dependency that aged out. Both behave the same way once they exist: they make the next change slower and riskier. The cause is worth understanding, but the response is the same.

How debt accrues

Debt rarely arrives in one large decision. It accumulates in ordinary, reasonable choices, each defensible on the day it was made:

A deadline is met by deferring the tidy-up that was meant to follow, and the tidy-up never gets scheduled.
A library or platform stops being maintained, and upgrading it keeps slipping because nothing is visibly broken yet.
A feature is bolted onto a structure that was never designed for it, because redesigning would cost more than the feature was worth.
The person who understood a part of the system leaves, and what was once a clear design becomes code nobody dares to touch.
A quick integration is wired in by hand, and the manual step quietly becomes permanent.

What it actually costs

The cost shows up in three places: slower delivery, more defects, and accumulating risk. The first is the one finance feels. In a McKinsey survey of 50 CIOs at financial-services and technology companies with revenues above one billion dollars, conducted in July 2020, 30 percent of CIOs believed that more than 20 percent of the budget nominally set aside for new products was actually being diverted to resolving issues related to technical debt. The same CIOs estimated that tech debt amounted to between 20 and 40 percent of the value of their entire technology estate before depreciation. It is worth noting the sample is small and skewed to large firms, but the direction is consistent with what smaller teams report informally.

The time cost is visible at the engineer’s desk too. Stripe’s 2018 Developer Coefficient study, conducted with Harris Poll across more than a thousand developers and a thousand C-level executives, found that developers spend more than 17 hours every week on maintenance issues such as debugging and refactoring, with roughly a quarter of that time spent fixing bad code. As reported by ADTmag and PYMNTS, the study put the resulting lost productivity at around 85 billion dollars globally each year, and nearly two-thirds of developers agreed the time spent fixing code was excessive.

The strategic cost is harder to see but more serious. Protiviti’s Global Technology Executive Survey of more than a thousand technology executives worldwide found that nearly 70 percent of organisations view technical debt as having a high impact on their ability to innovate, with respondents reporting that they dedicate on average around 30 percent of IT budgets and about 20 percent of resources to managing it. McKinsey’s research adds the sharpest figure on consequences: companies in the bottom fifth for tech-debt severity were about 40 percent more likely to have incomplete or cancelled IT modernisations than those in the top fifth. Debt does not just slow you down; past a point, it stops you finishing what you start.

Why it gets ignored

Knowing the cost is not the same as acting on it. In IDC’s 2023 CIO Sentiment Survey, reported by CIO.com, nearly four in ten CIOs expected to overspend on digital infrastructure over the following 18 months, and among those, 47 percent attributed the overspend to excessive technical debt and legacy applications. Yet the same CIOs still ranked AI and cybersecurity well ahead of eliminating tech debt on their priority lists.

That is the trap. Debt never makes a single quarter unworkable, so it never wins the argument against a visible new feature or an urgent threat. It loses every individual prioritisation call while quietly making all of them more expensive. Breaking that cycle needs the debt made visible and given a fixed claim on capacity, rather than left to compete ticket by ticket.

Measuring it without pretending to be precise

You cannot manage a liability you cannot see, but you do not need an exact figure either — you need something consistent enough to track over time and to argue with. Two layers work well together.

The first is a tool-based code measure. The Technical Debt Ratio, as defined in SonarQube’s documentation, expresses the estimated cost to fix the code as a fraction of the estimated cost to build it. SonarQube computes this as technical debt divided by the cost to develop one line of code multiplied by the number of lines, with the cost per line defaulting to 30 minutes, and maps the result onto maintainability bands: A is 0 to 5 percent, B is above 5 to under 10 percent, C is 10 to under 20 percent, D is 20 to under 50 percent, and E is 50 percent or more. A lower ratio is better. The number is approximate, but tracked release over release it tells you whether you are getting deeper into debt or climbing out.

The second layer is a plain debt register that the business can read: a short list of the known weak points, each with what it costs you now (the interest — slower changes, recurring incidents, a manual step someone repeats), what it would cost to fix, and what happens if you leave it. This is where an unsupported dependency or a fragile integration earns its place on the agenda, in language a non-engineer can weigh against everything else competing for money.

Paying it down without halting delivery

The instinct to stop everything and do a clean-up release almost always backfires: it delivers nothing visible for months, and the debt starts rebuilding the day you resume normal work. A steadier approach treats paydown as a continuous discipline rather than a project.

A common industry practice is to reserve a fixed slice of each delivery cycle for debt work, so reduction happens alongside new features rather than instead of them. The exact proportion matters less than the fact that it is protected and does not get traded away the first time a deadline tightens. Pair that with a simple rule: when you are already changing a part of the system, leave it a little better than you found it, so the areas you touch most often improve fastest.

On what to actually fix, DORA’s research on code maintainability gives credible direction. It identifies code maintainability as a practice that supports reliable delivery, and highlights two pillars worth prioritising: organisation-wide source-code management, so code is searchable and easy to discover and reuse, and effective dependency management, so teams can add and migrate dependencies easily and rely on them not to break. Those two tend to give the largest return per hour, because they make every future change cheaper rather than fixing one symptom.

Sequence the register by interest rate, not by how ugly the code looks. The debt to clear first is whatever is costing you most right now or carries the most risk — the dependency that is one upgrade away from a security problem, the fragile area that breaks every release — not the piece that merely offends an engineer’s taste. The prize for getting this right is real: McKinsey’s research found that paying down technical debt can free engineers to spend as much as 50 percent more of their time on work that generates value.

A short checklist

If you want a place to start, the following turns the above into a routine you can run quarterly:

Keep a debt register the business can read: each item with its current cost, its fix cost, and the risk of leaving it.
Track one code-level measure such as the Technical Debt Ratio over time, so you know the trend rather than guessing at it.
Protect a fixed share of every delivery cycle for paydown, and do not trade it away under deadline pressure.
Prioritise by interest rate and risk, not by appearance — fix what costs most now, starting with dependencies and discoverability.
Make the trade-off explicit when you take on new debt deliberately, and write down when you intend to pay it back.

The bottom line

Technical debt is not a sign that something went wrong. It is a normal cost of building software in a business that keeps changing, and the firms that handle it well are not the ones with none — they are the ones who can see it, price it, and pay it down at a steady rate that delivery can absorb. The goal is not zero debt. It is debt you chose, on terms you understand, kept small enough to carry.

When we take on a system someone else built, the first thing we do is make this liability visible — a register and a trend line before any rewrite — because the honest cost of carrying on is usually what decides what to fix first.