Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
How should you measure technical debt?
Updated
Measure technical debt with multiple proxy signals — code churn, complexity, defect density, and remediation cost — and track trends together. No single metric is authoritative. Each proxy has blind spots; combine evidence instead of one headline number.
Technical debt measurement, last verified 10 September 2026 against SEI (Carnegie Mellon) technical-debt research, ISO/IEC 25010:2023 quality model, DORA delivery and stability findings, and maintainability literature methodology. Illustrative trend example below is labelled, not YOUR data. Not legal advice.
Technical debt is a metaphor — measure proxies, not a balance sheet
Audience: an engineering leader, CTO, or platform owner prioritising remediation with evidence instead of gut feel. Technical debt describes deferred work that makes future change costlier — architecture shortcuts, missing tests, outdated dependencies, and unclear ownership.
No vendor, consultant, or single dashboard cell produces an authoritative debt total. SEI research treats debt as a portfolio of items requiring explicit tracking. ISO/IEC 25010 defines quality characteristics you can measure. DORA links delivery speed to stability trade-offs. This page is measurement guidance — not legal advice. Last verified 10 September 2026.
- Framework guidance versus org best practice versus ShipReady Metrics recommendation: ISO 25010 and SEI are frameworks. Your debt register is org best practice. SRM engineering risk score and DORA-style metrics are product measurements — labelled vendor methodology, not an industry standard.
- The does-ai-coding-increase-technical-debt guide on this site covers AI-specific debt risk. The measure-engineering-excellence guide on this site avoids single-metric distortion. The engineering-risk-score-explained guide on this site describes SRM composite scoring.
- Do not treat a cyclomatic-complexity threshold as a dollar debt figure unless you have a documented costing model — and even then, treat it as an estimate.
Proxy signals and blind spots
Use the table to pick complementary signals. Trend each proxy; argue about direction, not absolute level. Last verified 10 September 2026.
| Proxy signal | What it approximates | How to measure | Blind spots | Framework tie-in |
|---|---|---|---|---|
| Code churn | Unstable modules needing repeated fixes | Lines or commits changed per file over rolling window; hotspot maps | Active feature work looks like churn; ignores greenfield files; line counts bias language | SEI change-proneness research; DORA deployment frequency context |
| Complexity | Hard-to-change structure | Cyclomatic or cognitive complexity per module; depth of inheritance | Complex code may be inherently domain-heavy; metrics ignore readability and docs | ISO/IEC 25010 maintainability — complexity sub-characteristic |
| Defect density | Quality debt manifesting as bugs | Production defects or escaped bugs per KLOC or per service | Under-reporting in immature incident process; test debt hides latent defects | ISO/IEC 25010 reliability; SEI defect-debt linkage |
| Remediation cost | Effort to pay down items | Story points or hours on tagged debt tickets; time-to-fix recurring classes | Estimation bias; teams sandbag; does not capture opportunity cost | SEI technical-debt portfolio economics |
| Test coverage gap | Regression risk from missing tests | Line or branch coverage delta on critical paths | Coverage percentage without assertion quality; mocked tests inflate scores | ISO/IEC 25010 maintainability — testability |
| Dependency age | Supply-chain and upgrade debt | Count of majors behind; known CVEs on pinned versions | Fresh versions can still be vulnerable; rewrites may be unnecessary | SSDF PO.3 toolchain; KEV context for known exploitation |
| Change failure rate | Stability tax from fragile code | DORA metric: failed deployments or rollbacks / total deployments | Needs consistent incident definition; low deploy count skews ratio | DORA four keys — stability signal |
| Lead time on debt tickets | Organisational priority, not just code quality | Median age of open debt-labelled work | Label gaming; debt hidden in feature tickets | Org process metric — best practice |
No single number is authoritative
Goodhart's law applies: when a proxy becomes the target, it ceases to be a good proxy. A falling complexity score while defects rise is not improvement. A rising AI-authored-code share without review discipline may hide new debt — see the does-ai-coding-increase-technical-debt guide on this site.
Present leadership with a small dashboard of trends and narrative, not one debt dollar figure from a black box. ShipReady Metrics engineering risk score is a composite trend aid — vendor methodology, not an audit opinion.
Worked example — debt trend (illustrative only)
The table below is fabricated illustrative data for methodology demonstration — not YOUR codebase, not a ShipReady Metrics export, not a benchmark claim. Labelled illustrative only.
- Illustrative only: numbers are invented to show how to read combined trends.
- A single quarter drop in complexity without defect improvement would be a warning sign — not shown here.
- In production, annotate charts with known events: rewrites, team changes, AI coding rollout.
| Quarter | Hotspot churn (top 10 files, commits) | Median complexity (hotspots) | Escaped defects (prod) | Debt story points closed | Change failure rate | Interpretation (illustrative) |
|---|---|---|---|---|---|---|
| 2026 Q1 | 142 | 18 | 7 | 24 | 14% | High churn with rising defects — investigate hotspots before new features |
| 2026 Q2 | 118 | 17 | 5 | 31 | 11% | Remediation sprint lowered defects; churn still elevated |
| 2026 Q3 | 95 | 15 | 4 | 28 | 9% | Trend improving — complexity and failure rate down; keep debt budget |
Building a debt measurement practice
Org best practice steps. Not legal advice.
- Maintain a debt register: item, owner, proxy evidence, estimated remediation, priority.
- Pick three to four proxies from the signals table — not all eight at once.
- Review trends monthly; deep-dive quarterly with architects.
- Tie debt budget to capacity — visible percentage of sprint or kanban WIP.
- Separate AI-assisted churn from deliberate refactors using attribution where available.
What you need to do now
First steps for eng leaders. Not legal advice.
- List top ten churn hotspots from git history for the last 90 days.
- Tag open remediation tickets as debt with proxy evidence in the description.
- Add change failure rate if deploy and incident sources exist — DORA definitions on dora.dev.
- Share the illustrative trend format with leadership — replace with your real series.
- Read the engineering-risk-score-explained guide if you use SRM — understand coverage-as-confidence limits.
Checklist
Measurement readiness. Not YOUR debt total. Not legal advice.
- Debt register exists with owners and evidence links.
- At least three complementary proxies selected with blind spots documented.
- No single headline debt dollar presented without costing model disclaimer.
- Trend charts labelled with date range and known events.
- AI coding policy requires review on AI-touched hotspots.
- Leadership review cadence scheduled — monthly trends, quarterly deep dive.
- Product metrics (DORA, engineering risk score) interpreted as trends, not league tables.
Where this shows up in ShipReady Metrics
Honest product mapping. SRM does not produce a canonical debt dollar or SEI-certified assessment.
- Signed-in Delivery Health reports DORA-style deployment frequency, lead time, change failure rate, and recovery time when connected sources exist — shows Not measured when data is missing.
- Engineering risk score composites delivery, quality, and security-adjacent signals — vendor methodology on the engineering-risk-score-explained guide; not ISO 25010 certification.
- Security findings ingest highlights dependency and code issues that often map to debt items — prioritisation uses KEV, EPSS, and CVSS context on what-we-measure; not a debt register replacement.
- AI-authored-code floor in AI Code Readiness helps separate AI-driven churn from human refactors — attribution from git markers, not a classifier with certainty.
Primary sources (last verified 10 September 2026)
Methodology claims reference these sources. Peer-reviewed maintainability studies vary by context — cite methodology when you adopt a metric.
SEI (Carnegie Mellon Software Engineering Institute) technical-debt research portfolio — metaphor definition, change-prone modules, economic framing. ISO/IEC 25010:2023 — system and software quality models (maintainability, reliability sub-characteristics). DORA program and dora.dev — delivery stability metrics including change failure rate. Accelerate (Forsgren, Humble, Kim) — metric definitions and misuse cautions. Not legal advice.
Frequently asked questions
Can one metric tell us our total technical debt?
No. Each proxy in the signals table has blind spots. SEI treats debt as a portfolio of explicit items. Combine trends and a debt register instead of one authoritative number.
Is the worked example real ShipReady Metrics data?
No. The quarterly table is labelled illustrative only — fabricated numbers demonstrating how to read combined trends. Replace with your own series from git, incident, and ticket systems.
Does the engineering risk score equal technical debt?
No. Engineering risk score is a ShipReady Metrics composite described on the engineering-risk-score-explained guide. It trends quality and delivery signals — vendor methodology, not an ISO 25010 audit or SEI debt valuation.
How does AI coding affect debt measurement?
AI-assisted changes can increase churn and shortcut tests. The does-ai-coding-increase-technical-debt guide on this site covers AI-specific risks. Use attribution and review discipline when interpreting hotspots.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.