How to Calculate Technical Debt

Part 6 explained what the technical debt ratio means and where it misleads. This part answers the mechanical question underneath it: where do the numbers come from, and how much should you trust each one? The aim is not to make you a tool operator — the tools compute this automatically — but to let you read any technical-debt number you are handed and know exactly what it is, and is not, telling you.

A clarification first, because the field is muddy with vendor formulas. There is no secret, proprietary equation for technical debt. The standard, established calculation is the technical debt ratio, and it is simple arithmetic over two estimated quantities. The difficulty is never the formula. It is the honesty of the inputs.

The standard formula

Technical Debt Ratio = (Remediation Cost ÷ Development Cost) × 100

That is the whole of it. The ratio is the cost to fix the system’s known issues as a percentage of the cost to build the system. Everything that follows is about how each of those two costs is derived — and every term carries an assumption worth seeing plainly.

Step 1 — calculate remediation cost

Remediation cost is the estimated effort to fix everything a static-analysis tool has detected. It is built in three moves:

1. Detect the issues. The tool scans the codebase against a ruleset and produces a list of findings — complexity above a threshold, duplicated blocks, missing coverage, known anti-patterns, rule violations.
2. Estimate a fix-time per issue. Each finding is assigned a remediation time from the tool’s built-in model — a few minutes for a trivial smell, longer for a complex one.
3. Sum them. The per-issue times add up to a total remediation effort, usually expressed in person-days, and convertible to money by applying a cost rate (more on that below).

The assumptions to see clearly: the per-issue fix-times are averages baked into a model, not estimates of your specific code, so a single finding may be far cheaper or costlier to fix than the model assumes — though across thousands of findings the averages are more defensible than any one of them. More importantly, the total only counts issues the tool can detect, which means it is overwhelmingly a measure of code debt. The architectural debt, knowledge debt, and most of the test and documentation debt from Part 2 are simply absent from this number — not because they are small, but because static analysis cannot see them. A remediation cost is a real estimate of a partial picture.

Step 2 — calculate development cost

Development cost is the estimated effort to build the system in the first place. It is almost always derived from size: take the lines of code (or an equivalent size measure), and multiply by an assumed cost-per-unit drawn from a model.

The assumption here is blunter than it looks. Deriving build cost from size assumes that lines of code are a reasonable proxy for the effort a system represents — which is true on average and false in any specific case, since the value-per-line of a dense domain rule and a generated boilerplate file are nothing alike. It is a serviceable denominator for producing a ratio and a poor estimate of what the system actually cost to build. You are not meant to read the development-cost figure as a real budget. It exists to normalize the remediation cost into a percentage that can be compared across systems and over time.

Step 3 — compute the ratio

With both costs in hand, the ratio is one division. Take the worked example from Part 6: 50 days of estimated remediation against 1,000 days of estimated development.

(50 ÷ 1,000) × 100 = 5%

Five percent of the system’s build effort is represented by its detected issues — which, by the convention from Part 6, sits right at the edge of “healthy.” Notice what the single number has hidden: it says nothing about where those 50 days of debt sit, or how often that code changes. Two systems with an identical 5% ratio can carry wildly different real costs depending on whether the debt is in the hot path or the attic. The ratio is the start of the analysis, not the end of it.

Putting a dollar figure on it

Leaders, reasonably, want money rather than a percentage — and you can get there. Apply a loaded engineering cost rate to the remediation effort:

Estimated remediation cost ($) = remediation effort (days) × loaded daily engineering cost

If the tool estimates 50 days and a loaded engineering day costs, say, a few thousand dollars in your organization, you have a dollar figure for clearing the detected code debt. Our legacy cost calculator runs this same math against your own inputs — effort, rate, and the cost of carrying the system another year — so you leave with a defensible range rather than a hand-wave. This is genuinely useful input for the business case in Part 11, and it connects to the larger economics in the legacy series’ cost of modernization piece — a remediation estimate is one component of a modernization cost.

But present it honestly, or it will be torn apart by the first skeptic in the room. The number rests on model-based effort estimates and a cost rate and covers only what the tool can see. The defensible form is a range with stated assumptions — “clearing the detected code debt is on the order of X to Y engineer-months, which does not include architectural or knowledge debt the tools can’t measure” — not a single confident figure that invites a fight about the third significant digit. A credible range you can defend beats a precise number you cannot.

What the calculation deliberately leaves out

It is worth stating the omissions as a set, because the gap between what the formula computes and what debt actually costs is where misuse lives:

• The interest, not just the principal. The remediation cost is the principal — the one-time price of fixing the issues. It is silent on the interest, the recurring drag the debt imposes until it is fixed, which Part 4 argued is the cost that actually dominates. The most important cost is the one the formula does not contain.
• Change frequency. No term in the formula knows which code is hot and which is cold, so it cannot tell expensive debt from cheap debt.
• The invisible types. Architectural, knowledge, and most test and documentation debt are outside the tool’s reach and therefore outside the number.

This is not a reason to discard the calculation. It is the reason to pair it, as Part 5 insisted, with delivery data and qualitative signals — the lenses that catch exactly what the formula drops.

The false-precision trap

Calculating technical debt produces a number, and numbers carry an authority their inputs do not earn. The greatest risk in this whole exercise is false precision: quoting “our technical debt is $1.2M” as though it were a measured liability, when it is a model estimate of a partial picture multiplied by an assumed rate. Used as a directional, consistently-measured signal — is it rising, where does it concentrate, roughly what order of magnitude — the calculation is valuable and defensible. Used as a precise dollar figure to be cited to two decimal places, it will eventually be exposed as softer than it sounded, and it will take the credibility of your whole debt program down with it. Calculate it. Then present it as the estimate it is.

Where this leads

We can now measure debt across three lenses and calculate the headline numbers honestly. But measurement and calculation are diagnosis, not treatment — a dashboard full of accurate debt metrics changes nothing on its own. The work is turning those numbers into decisions, repeatedly, as part of how the organization runs. Part 8, Technical Debt Management Framework, assembles everything so far into an operating system for debt: how to track it, prioritize it, fund its repayment, and govern it so it never silently compounds again.