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?
Last verifiedMeasure 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 |
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.