Why technical debt behaves like a loan
Ward Cunningham's original metaphor was precise about one thing that later retellings blur: debt is not the messy code, it is the interest the messy code charges on every future change. The principal is what it would cost to clean it up. The interest is what you pay every sprint whether or not you ever clean it up, in slower changes, rework, failed deployments and defects that trace back to the same structural cause.
That distinction is what makes the decision calculable. Interest is a recurring cost measured in capacity — a share of your team's total capacity that produces no delivery. Multiply that share by the fully loaded cost of the team and you have an annual dollar figure that sits alongside every other line in the engineering budget. The principal is a one-off effort in engineer-weeks, priced the same way any project is priced.
Once both are in dollars, the question stops being a values argument between engineers and managers and becomes an ordinary capital decision: does a one-off payment of C that removes a recurring cost of S per year clear the hurdle rate over the system's remaining life? That is the same question the cloud migration payback calculator asks about a data centre exit, with the same arithmetic.
The metaphor also warns you where it breaks. Real debt has a contractual interest rate; this one is an estimate, and it is the input with by far the widest uncertainty. Everything below is only as good as your evidence for the drag percentage.
Measuring the drag, then pricing it
The drag percentage is the share of total team capacity consumed by the debt — not the share of a single change that goes wrong, and not a productivity score. Four sources make it measurable rather than guessed. Cycle-time comparison: how long an equivalent change takes in the affected area versus a clean one. Rework rate: the proportion of changes that require a follow-up fix. Change failure rate and the recovery time behind it, which the DORA research programme defines and measures directly. And the standing tax: manual steps, environment fiddling and coordination that a healthier design would not require.
Value it at fully loaded cost, not salary. An engineer's true annual cost includes benefits and overhead, and if you do not have that figure the fully loaded engineering hour calculator derives it. Using base salary understates the interest by whatever your load factor is: at a load factor of 1.53, salary is 1 ÷ 1.53 = 65.4% of loaded cost, so the interest comes out about a third too low.
The payoff is priced in engineer-weeks, converted through the same loaded cost. Six engineers for ten weeks is 60 engineer-weeks, and at $245,000 per engineer over 46 delivery weeks a year, each engineer-week costs $5,326. Dividing by delivery weeks rather than by 52 is deliberate: leave weeks are paid but produce nothing, so an engineer-week of actual work carries their cost.
Residual drag is where most cases are won or lost. A refactor rarely returns a system to zero friction; it moves it to a lower level. The saving is the difference between the two drag levels, not the whole of the current drag, and a case built on the whole of it will be roughly one residual-percentage-point too optimistic for every year of the horizon.
The last output has a closed form worth knowing. Postponing the work by a year forgoes one year of saving but lets you keep the payoff cost for another year, earning the discount rate on it. The present value given up is (S − C·d) / (1 + d), and the horizon cancels out entirely — the cost of a year's delay is the same whether you are planning over five years or ten. It is negative when the annual saving is smaller than the interest on the payoff cost, which is the mathematical statement of "this is genuinely not urgent yet".
Worked example: eight engineers, 25% drag, 60 engineer-weeks to fix
Take the defaults: eight engineers at $245,000 fully loaded, 46 delivery weeks each, 25% of capacity lost to the debt, 8% expected to remain afterwards, 60 engineer-weeks of work, a five-year horizon and a 10% discount rate.
- Total the team. 8 × $245,000 = $1,960,000 a year.
- Price the interest. $1,960,000 × 25% = $490,000 a year of capacity lost to the debt.
- Price what remains after the work. $1,960,000 × 8% = $156,800.
- Take the saving. $490,000 − $156,800 = $333,200 a year.
- Cost one engineer-week. $245,000 ÷ 46 = $5,326.09.
- Price the payoff. 60 × $5,326.09 = $319,565.
- Divide for payback. $319,565 ÷ $333,200 = 0.959 years, and 0.959 × 12 = 11.5 months.
- Discount the savings. The five-year annuity factor at 10% is (1 − 1.10⁻⁵) ÷ 0.10 = 3.790787, so $333,200 × 3.790787 = $1,263,090.
- Net it off. $1,263,090 − $319,565 = $943,525 of net present value.
- Price a year's delay. ($333,200 − $319,565 × 0.10) ÷ 1.10 = ($333,200 − $31,957) ÷ 1.10 = $273,858.
Read the last figure carefully, because it is the one that changes conversations. Deferring this work by a single quarterly planning cycle is not free and not cheap: a full year's postponement destroys $273,858 of present value, which is more than eight tenths of what the work costs to do.
How to read the result
Compare the annual interest against the payoff cost first. When the interest exceeds the payoff — as it does in the worked example, $490,000 against $319,565 — the work repays itself in under a year, and the case is close to unarguable provided the drag estimate holds. When the payoff is several times the annual interest, the case depends heavily on the horizon, and the horizon depends on how long the system will really live.
Treat the horizon as the honest constraint it is. A five-year NPV on a system slated for replacement in two years is fiction. Set the horizon to the remaining life you would defend in front of the person who owns the roadmap, and if the answer is under two years the right move is usually to contain the debt rather than repay it.
Watch the residual assumption. Re-run the case with the residual set a few points higher than your estimate. If the NPV survives, you have a robust case. If it collapses, what you have is a case that depends on a refactor going perfectly, and refactors that go perfectly are not the modal outcome.
Do not use the annual interest as a productivity target. The figure says how much capacity is consumed by structural friction; it does not say the team would deliver 25% more features tomorrow if the debt vanished. Some of the recovered capacity goes into the next thing that was being deferred. Quote it as the cost of the friction, which is defensible, rather than as a promised throughput gain, which is not.
Annual interest by team size and drag level
| Engineers affected | 10% drag | 20% drag | 30% drag |
|---|---|---|---|
| 4 | $98,000 | $196,000 | $294,000 |
| 6 | $147,000 | $294,000 | $441,000 |
| 8 | $196,000 | $392,000 | $588,000 |
| 12 | $294,000 | $588,000 | $882,000 |
| 20 | $490,000 | $980,000 | $1,470,000 |
The worked example sits between the 20% and 30% columns on the eight-engineer row: at 25% it is $490,000, the same figure the twenty-engineer team reaches at 10% drag. Debt in a large team is expensive at any severity.
Where these cases go wrong
- Guessing the drag percentage. It is the input the whole result scales with, and an unevidenced number invites the reviewer to substitute their own. Bring cycle-time or rework data, or present a range and show the NPV at both ends.
- Setting residual drag to zero. This claims a perfect refactor and inflates the saving by the residual amount every year of the horizon. A few points of residual is realistic and makes the case credible rather than weaker.
- Confusing engineer-weeks with calendar weeks. Six people for ten weeks is 60 engineer-weeks. Entering 10 understates the payoff cost sixfold and produces a payback period nobody will believe once they check it.
- Using base salary instead of loaded cost. Both the interest and the payoff scale with the same figure, so the payback period survives the error — but the NPV and the annual interest, which are what get quoted, do not.
- Counting engineers who never touch the system. The drag applies to the capacity working in the affected code. Counting the whole department inflates the interest without inflating the payoff, which quietly doubles the apparent return.
- Assuming the debt stays constant while you wait. This model holds drag flat. In an actively changing system it usually grows, which means the cost of postponing is a floor rather than a central estimate.
Not all debt is worth repaying
Debt in a system with two years left, low change frequency and no incident history is debt you should keep servicing rather than repay. The interest is small because the capacity flowing through it is small, and the payoff cost is unchanged. This calculator will tell you that directly through a negative NPV or a payback period beyond the horizon, and that is a legitimate answer, not a failed case. The strategic error is not carrying debt — it is carrying it without knowing what the interest is.
How this fits alongside the other engineering cost cases
Technical debt shows up in three budgets at once, and this calculator only measures one of them. The delivery cost is here. The reliability cost — debt that causes outages — belongs in the incident response cost calculator, and if the same structural cause drives repeated incidents you should count it once in each place but never add the two into one headline figure without saying so. The opportunity cost, work not started because capacity was consumed, is real but not reliably quantifiable, and it is better argued than estimated.
If you run service-level objectives, the error budget is a useful cross-check on the drag estimate: a system that consistently burns its budget is telling you the friction is real. The error budget calculator converts an availability target into the minutes you can actually spend.
Finally, when the payoff cost approaches the cost of replacing the system entirely, stop and run the replacement case instead. The build versus buy calculator and the software TCO calculator price that alternative properly. Paying down debt in a system you should be retiring is the most expensive form of diligence there is.
Key terms
- Interest (in the debt metaphor)
- The recurring cost the debt imposes on every future change, whether or not it is ever repaid. Measured here as team capacity lost per year.
- Principal
- The one-off effort required to remove the debt, priced in engineer-weeks at fully loaded cost.
- Residual drag
- The friction expected to remain after the work. The saving is the difference between current and residual drag, not the whole of the current drag.
- Engineer-week
- One engineer working for one week. Six engineers for ten weeks is sixty engineer-weeks.