Technical debt: what it costs and when to pay it down

The metaphor comes from Ward Cunningham. In a 1992 experience report, he wrote that a little debt speeds up development as long as it’s paid back promptly. “Every minute spent on not-quite-right code counts as interest on that debt,” he added (Cunningham, 1992). The term is often shortened to tech debt.

At a research seminar at Schloss Dagstuhl in 2016, the participants agreed on a working definition. Technical debt, they wrote, is a collection of design or implementation constructs that are expedient in the short term and can make future changes more costly or impossible. Under that definition, its impact is limited to a system’s internal qualities, primarily maintainability and evolvability (Dagstuhl Seminar 16162, 2016).

Martin Fowler shows what the math looks like. A new feature takes four days in a clearly structured module and six in a confusing one. The two days’ difference is the interest. Five days of cleanup would be paying off the principal (Fowler, Technical Debt, 2019). Unlike with a bank loan, you only pay this interest when someone changes that code. SaaS products are usually under continuous development, so you often pay it there. Our guide What is SaaS? explains how SaaS works.

Martin Fowler sorts technical debt by two questions: Was it taken on deliberately, and was that prudent or reckless (Fowler, Quadrant, 2009)?

• Deliberate and prudent: The team knows about the compromise and weighs whether an earlier release is worth the later cost.
• Deliberate and reckless: The team knows good practice but skips it for lack of time. Fowler sees this as a misjudgment in most cases, because clean design speeds up the work.
• Inadvertent and reckless: The team lacks knowledge of good design. It doesn’t notice how much debt it’s taking on.
• Inadvertent and prudent: A good team only realizes during the work what the design should have been. According to Fowler, that’s hard to avoid.

According to Google’s Engineering Productivity Research team, taking on debt prudently and deliberately “can be a correct engineering choice.” The same article notes that Cunningham didn’t intend the term as an excuse for bad code (Google, IEEE Software, 2023). At the Dagstuhl seminar, Frank Buschmann of Siemens summed it up this way: the goal is a competitive system, and it doesn’t have to be debt-free.

In a family of surveys with 653 valid responses from six countries, time pressure was the most frequently cited cause of technical debt. The most frequently cited effects were delivery delays, low maintainability and rework (Ramač et al., 2022).

Google asked its engineers to name the causes of their debt and arrived at 10 categories. The ranking depends on the company, but the authors consider the list itself generalizable (Google, IEEE Software, 2023). The table translates all 10 into what you’d notice as the client. The left column is our own interpretation.

Small businesses should pay special attention to the third row, because in small teams, knowledge often sits with just a few people. Our how-to Avoiding developer lock-in shows how to check this. If a small internal tool runs reliably and rarely changes, you pay almost no interest and the issue can wait.

The table sorts well-known figures by how they were produced. The numbers in the “Source” column refer to the source list at the end of this article.

We haven’t found reliable figures for small businesses. Paying down debt doesn’t work automatically, either. In 10 open-source projects of the Apache Software Foundation, most of 4,166 refactorings, meaning changes to the code that add no new functionality, reduced the measured interest. Across all cases, however, no average effect could be shown (Nikolaidis et al., 2022). At Microsoft, developers saw substantial costs and risks in refactoring (Kim et al., 2014). So it comes down to which area of the code you tackle.

For prioritizing, what counts is where work actually happens. According to the Dagstuhl report, debt in code that will be extended for the next release weighs more than debt in untouched areas. Fowler also leaves stable code alone. A 2024 study recommends preventing new flaws above all in frequently changed files (Borg et al., 2024).

Use these questions to rate an area of code. We compiled the grid from these sources; the buffer and the thresholds are our own judgment.

That gives you two values:

• Interest per year: changes per year times extra effort per change, plus defects per year times effort per defect.
• Payback period: paydown effort divided by interest per year.

The section When are version upgrades due? shows when components reach end of support.

Here’s how we calculated it:

• Paydown: an estimated 40 hours, or 60 hours with the 50% buffer, one-time and up front. At €125 an hour, that’s €7,500.
• Interest per change: 3 hours, so the work takes 7 hours instead of 4. That’s 75% extra effort; the middle tier in the measurement above came in at 78%.
• Interest per defect: 2 additional hours.
• Hourly rate: €125, the median hourly rate without a maintenance package in our survey of software providers based in Germany.
• Remaining service life: four years.
• Interest over four years: 176 hours in case A, 88 in case B and 32 in case C, that is, four times the interest per year. These are the values in the chart.
• Simplifications: constant interest, no discounting and no cost of outages. These aren’t Datafalke prices or quotes.

Applied to the grid, that means: pay down case A, include case B the next time the area is reworked and leave case C alone. As a check, rerun the numbers with a third fewer changes. Case A would then pay off after about 23 months and stay under half the remaining service life. Case B would land at 45 months, only just inside the four years.

• Keep a list: The arc42 architecture template has its own section for this, with risks and technical debt ordered by priority (arc42, section 11). For each entry, the area, interest, paydown effort, decision and date are enough.
• Add tests first, then rework: Automated tests capture what the code does today, so you’ll notice if the rework changes anything.
• Pay down as you go: Rework an area when a change is already due. That’s where you pay the interest.
• Take on new debt deliberately: A shortcut is fine if it’s on the list and has a date for repayment.
• Don’t rewrite everything: A complete replacement sounds simple. But Fowler has seen that plan “go down in flames most of the time,” in part because existing behavior is hard to pin down. He recommends replacing a legacy system gradually (Fowler, Strangler Fig, 2024).

Sometimes off-the-shelf software is the better replacement. Our comparison Build or buy software? covers that decision.

The numbers in the “Source” column refer to the source list at the end of this article.

Our cost guide How much does software maintenance cost? covers what maintenance includes and what it costs.