Technical Debt Ratio Explained

Part 5 laid out three lenses for measuring debt and noted that code-analysis tools tend to collapse their findings into a single headline number. The technical debt ratio is that number — the metric you are most likely to be handed in a tool dashboard, and the one most likely to be misread in a leadership conversation. This part is for the technical leader who has to interpret it: what it actually means, what a defensible threshold looks like, and the specific ways it will mislead you if you read it without context.

The ratio is genuinely useful. It is also routinely over-trusted, precisely because it looks like a definitive answer to a question that does not have one. Both things are true, and a leader has to hold them at once.

What the ratio is

The technical debt ratio expresses debt as a fraction of what the system is worth building:

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

Remediation cost is the estimated effort to fix all the issues a static-analysis tool has detected — its findings, each assigned a notional time to fix, summed. Development cost is the estimated effort to build the system in the first place, usually derived from its size (lines of code or a similar proxy) times a cost-per-unit. The result is a percentage: the share of the build cost that the outstanding issues represent.

A worked example makes it concrete. If a tool estimates 50 days to fix everything it found, and estimates the system would take 1,000 days to build, the ratio is (50 ÷ 1,000) × 100 = 5%. We walk through every term of this calculation — where each number comes from and how much to trust it — in Part 7. Here the focus is interpretation.

What counts as a “good” ratio

The widely repeated convention treats under ~5% as healthy, with rising values flagged for attention and grading bands assigned above that. Many tools ship that threshold as a default and grade your codebase against it.

Take the threshold seriously and lightly at the same time. Seriously, because a consistent, transparent benchmark is genuinely useful for triage and for spotting a codebase that is sliding. Lightly, because the absolute number is far less informative than two things the threshold ignores: the trend and the context.

The trend matters more than the level. A system holding steady at 8% is in better shape than one that has climbed from 3% to 6% in two quarters, because the second is accelerating and the first is not. Debt is a flow problem; a single reading cannot see flow. This is the same lesson as Part 5 — measure the direction of travel, not the snapshot — applied to the one metric most often quoted as a snapshot.

The three ways the ratio misleads

The technical debt ratio is best understood by what it cannot see. Three blind spots account for most of the bad decisions made on the strength of it.

It is blind to change frequency. This is the most important and most ignored limitation. The ratio treats every line of code as equally costly, but Part 4 established that the cost of debt is an interest rate, charged only where you actually work. A 5% ratio concentrated in your most-changed payment path is far more expensive than a 15% ratio sitting in a stable module nobody touches — yet the ratio rates the second as worse. Read on its own, TDR will steer repayment effort toward the loudest debt rather than the costliest. The churn-weighted view from Part 5 is the corrective.

It sees only what static analysis can detect. The remediation cost is built from tool findings, and tools find code debt — complexity, duplication, known anti-patterns, rule violations. They are largely blind to the debt that Part 2 identified as the most expensive: architectural debt (a bad boundary is not a rule violation), knowledge debt (a tool cannot detect what nobody remembers), and most test and documentation debt. A system can have an excellent ratio and a catastrophic architecture. The number that looks comprehensive is measuring the cheapest, most containable category.

Both inputs are estimates, not measurements. Remediation cost assigns a notional fix-time to each finding; development cost is inferred from size. Neither is a fact — they are model outputs, and the model can be tuned. This is why the absolute value deserves skepticism and the consistently-measured trend deserves attention: whatever the model’s biases, they stay roughly constant, so the direction remains meaningful even when the level is shaky.

How a leader should use it

Given all that, the ratio still earns a place — used for what it is. Three legitimate uses:

• Trend tracking. Watch the direction over quarters. A rising ratio is an early warning that debt is outpacing repayment, worth investigating before delivery metrics confirm it the hard way.
• Triage and hotspots. Use it at the module level, crossed with change frequency, to point toward where code debt concentrates in code you actually work in. That intersection is a credible repayment target.
• One input among three. Place it alongside the delivery data and qualitative signals of Part 5. When the ratio is high and lead time is rising and engineers dread the area, you have a conclusion. The ratio alone is a hypothesis.

What the ratio cannot do is settle a prioritization argument or stand in for a business case. A CTO who walks into a budget meeting with a debt ratio and nothing else will be asked, correctly, what it costs the business — and the ratio does not answer that. The translation from metric to money is the work of Part 11.

Don’t manage the number

There is a real temptation to manage the ratio instead of the debt. Because it is a single visible number with a published threshold, it invites being set as a target — and the moment it becomes a target it stops measuring anything (Goodhart’s law again, from Part 5). Teams can drive the ratio down by suppressing findings, tuning rules, or refactoring trivial code that was never charging interest, all while the architecture quietly rots where the tool cannot see. The ratio is a symptom reading, useful for noticing and triaging, never a goal to be optimized. If the number is improving while lead time worsens and engineers grow more frustrated, the number is lying and the people are telling the truth.

Where this leads

We have interpreted the ratio — what it means, what “good” looks like, and where it misleads. The natural next question is mechanical: where do the numbers in that formula actually come from, and how much should you trust each one? Part 7, How to Calculate Technical Debt, works the standard calculation end to end — remediation cost, development cost, and the ratio — with an honest account of the assumptions baked into every term, so you can read any tool’s output knowing exactly what it is and is not telling you.