How to Measure Technical Debt

Part 4 argued that technical debt’s cost is enormous and invisible — paid continuously, diffusely, and under other names. Measurement is the intervention that makes it visible. You cannot manage, prioritize, or fund the repayment of something you have only described in adjectives. This part is about turning “we have a lot of tech debt” into evidence a leadership team will act on.

The honest opening: there is no thermometer for technical debt. Anyone selling a single, definitive “debt score” is selling precision the problem does not have. Debt spans the six types of Part 2 — code, architectural, test, documentation, dependency, knowledge — and no one metric sees all six. What works is triangulation: three lenses that each catch what the others miss, measured consistently over time. Measuring imperfectly but consistently beats measuring perfectly once, because the signal that changes decisions is the trend, not the snapshot.

Lens 1 — qualitative signals

The cheapest, fastest, and most under-used measurement is to ask the people who work in the code every day. They already know where the debt is. They know which modules everyone dreads, which changes always take three times the estimate, which area no one will touch without the one engineer who understands it. The measurement task is to extract that knowledge systematically rather than leaving it as folklore.

Practical instruments:

• A debt-mapping survey. Ask engineers to rate each major area on how painful it is to change and how often they have to change it. The overlap — high pain, high frequency — is your highest-interest debt, and it usually surfaces in an afternoon.
• Friction logging. For a few sprints, have engineers tag work that was slowed by existing debt. This converts the diffuse “this took longer than it should have” of Part 4 into a count, and counts aggregate where individual frustrations do not.
• The newcomer signal. A recent hire’s onboarding friction is an unusually honest debt measurement, because they have no learned tolerance for it yet. Where they get stuck is where the documentation and knowledge debt is worst.

Qualitative signals are sometimes dismissed as subjective. They are subjective — and they are also the only lens that sees architectural and knowledge debt clearly, which the tools largely cannot. Treat them as primary evidence, not color commentary.

Lens 2 — code metrics

The second lens is static analysis: metrics computed directly from the code. These are objective, automatable, and good at finding code debt — and weak at everything else, which is the limitation to hold in mind.

The metrics worth tracking:

Metric	What it indicates	What it misses
Cyclomatic complexity	How tangled the control flow is; change risk	Says nothing about whether the complexity is necessary
Code duplication	Copy-paste that multiplies the cost of every fix	Blind to architectural and knowledge debt
Test coverage	The size of your safety net; test debt	High coverage of trivial code can flatter a weak suite
Static-analysis findings	Known anti-patterns, code smells, security issues	Counts symptoms, not the cost of living with them
Churn × complexity	Complex code that also changes often — highest interest	Needs version-control history to compute

That last row is the most valuable thing in the table. Complexity alone is not debt that matters — a complex module nobody touches charges no interest. Complexity layered on high churn is your most expensive debt, because you are paying the complexity tax repeatedly. Overlaying change frequency from version control onto complexity is one of the best signals available for where to spend repayment effort, and it directly operationalizes the “interest rate, not balance” framing from Part 4.

Many tools aggregate these into a single estimate — a remediation cost, or a technical debt ratio. That number is genuinely useful for trend-tracking and triage, with two caveats: it measures only what static analysis can see (mostly code debt), and the absolute value is far less meaningful than its direction over time. We give that metric its own treatment in Part 6 and walk through the underlying calculation in Part 7.

Lens 3 — delivery data

The third lens is the most important and the most often skipped, because it measures debt by its effect rather than its appearance. Code metrics tell you the code looks bad; delivery metrics tell you it is expensive to change — which is the actual definition of debt from Part 1.

The DORA metrics are the established vocabulary here:

• Lead time for changes — how long from committing a change to running it in production. Rising lead time is debt slowing you down.
• Deployment frequency — how often you can safely ship. Debt makes each deployment riskier, so frequency falls.
• Change-failure rate — the share of changes that cause a problem. Debt makes correct change harder, so failures rise.
• Time to restore service — how fast you recover from an incident. Tangled systems are slow to diagnose.

Beyond the four DORA metrics, escaped-defect rate, the bugs that reach production per unit of work shipped, is a useful adjunct. It measures the quality tax debt imposes. When the code fights back, more defects slip through the net, and the ones that escape are the expensive ones to fix. Rising escaped defects alongside a rising change-failure rate is debt showing up as the unreliability your customers actually feel, which is often the version of the problem a leadership team notices first.

These metrics are powerful for the technical-debt argument because they translate directly into the language Part 4 set up: lead time is the interest rate made visible. And they connect to outcomes leadership already cares about — predictability, reliability, speed — which is why they carry weight in a business case where a complexity score does not. Their limitation is that they show debt’s symptoms without locating the debt; that is what lenses 1 and 2 are for. Used together, delivery data tells you that you have a problem and how big, while code metrics and qualitative signals tell you where it is.

The metrics at a glance

Before combining the lenses, it helps to see the whole toolkit in one place. This is what to actually measure, where each signal comes from, and the blind spot that stops any one of them from being the whole answer.

Lens	What to measure	Where it comes from	Sees best	Blind to
Qualitative	Debt-mapping survey, friction logs, newcomer friction	The engineers in the code	Architectural and knowledge debt, and where the pain actually is	Objectivity and precision
Code	Complexity, duplication, coverage, static-analysis findings, churn × complexity	Static analysis plus version-control history	Code debt, and where to target repayment	Everything that is not code-level
Delivery	Lead time, deployment frequency, change-failure rate, time to restore, escaped-defect rate	Your deployment and incident pipeline	The scale, trend, and business impact of debt	Where the debt physically lives

No row is sufficient alone, which is the entire reason the next section is about combining them. Reach for delivery data to size the problem, code metrics to target it, and qualitative signals to catch the debt the tools cannot see.

Triangulating into a picture leaders act on

The three lenses are complementary by design, and the synthesis is where measurement becomes decision-support:

• Delivery data establishes the scale and trend — the headline a leadership team responds to (“lead time has doubled in eighteen months”).
• Qualitative signals point to where the debt concentrates and catch the architectural and knowledge debt the tools miss.
• Code metrics add objective detail and, via churn-weighted complexity, sharpen the targeting to the highest-interest areas.

Where all three agree — engineers dread a module, its churn-weighted complexity is high, and changes there have a high failure rate and long lead time — you have not just measured debt, you have located your most expensive debt with evidence from three independent sources. That convergence is what survives scrutiny in a prioritization meeting, and it is the foundation for the management framework in Part 8.

Presenting it to leadership

Measurement only pays off if it changes a funding decision, and that decision gets made in a room where most people do not read code. The translation from three lenses to one slide is a separate skill, and getting it wrong wastes the measurement.

Lead with delivery data, because it is already in the language leadership uses. “Lead time for a routine change has gone from two days to nine over the past year” lands. “Average cyclomatic complexity is fourteen” does not. Put the trend first, framed as the interest payment from Part 4. This is what the debt costs us in speed and reliability right now, every sprint, whether or not we ever choose to repay it.

Then show where, not everything. The instinct is to hand over the full static-analysis report, but a wall of several hundred findings reads as noise and invites the worst possible response, “so fix them all,” which is neither fundable nor wise. Name two or three concentrations instead, the places where all three lenses agree, and show that they account for a disproportionate share of the pain. Three named, evidenced targets are a decision. Five hundred smells are a shrug.

Close with the ask in their terms. What would repaying the top concentration cost, roughly, and what would it buy, stated as the delivery outcome that improves. Faster releases, fewer failed changes, a module a new hire can safely touch in week one instead of month three. Leadership funds outcomes, not remediation. “Refactor the billing module” is a cost. “Halve billing change lead time so we can finally ship the pricing work sales keeps asking for” is an investment.

A useful discipline is that the leadership view fits on one page with three parts, the trend, the concentration, and the ask. If it needs an appendix of metrics to make its case, the case is not yet clear. Keep the vanity metrics out of the deck entirely. Coverage percentage and smell counts belong in the engineering backlog, not in front of a CFO, because they pull the conversation toward arguing about a number and away from the decision the number was meant to support.

Measure the trend, not the moment

The most common measurement mistake is the one-off audit: a quarter spent producing a definitive snapshot that is read once and shelved. A snapshot answers “how much debt do we have?” — which is almost unanswerable and not very useful. The trend answers “is debt growing or shrinking relative to our delivery, and is our repayment working?” — which is both answerable and decision-relevant.

So the design goal for measurement is durability, not precision. Wire it into tooling that already runs — static analysis in CI, DORA metrics from your deployment pipeline, the debt survey on a light recurring cadence — so the numbers update without a heroic effort. A measurement that depends on a quarterly manual push will quietly lapse the first time a deadline crowds it out, and then you are back to adjectives. Modest metrics collected automatically and forever beat excellent metrics collected once.

When the metric becomes the target

Measurement has a failure mode worth naming: the metric becomes the target. Optimize for a coverage number and you get tests that assert nothing; optimize for a complexity score and you get logic split into more files without becoming simpler. Goodhart’s law applies in full — once a measure becomes a goal, it stops measuring. The defense is to keep the measurement in service of the decision, not the other way around: these numbers exist to locate debt worth repaying and to track whether repayment is working, never as KPIs to be maximized for their own sake. And no measurement, however good, makes the prioritization decision for you — it informs a judgment that still has to weigh the debt against the roadmap. The numbers are evidence for a decision, not a substitute for making one.

Where this leads

We now have a way to make debt visible across three lenses. The next two parts go deep on the single most cited measurement, because it is the one a leader is most likely to be shown and most likely to misread. Part 6, Technical Debt Ratio Explained, unpacks the metric — what it actually represents, what a “good” number is, and the specific ways it misleads when read without context — before Part 7 shows exactly how it is calculated.