Home/Measure

How to Measure Technical Debt

You cannot manage what you cannot measure. This guide covers the four most reliable approaches to quantifying technical debt, the tools that support each method, and how to combine them into a credible assessment you can present to engineering leadership.

1. Developer Surveys

The fastest and most practically accurate measurement method. Engineers experience debt directly every day and can estimate its drag with reasonable precision. A well-structured survey takes 10 minutes and gives you actionable data within a week.

Core Questions to Ask

  • 1.What percentage of your week goes to debt-related work versus new feature development?
  • 2.Name the top 3 areas of the codebase that slow you down the most.
  • 3.How much longer does onboarding a new engineer take compared to an ideal codebase?
  • 4.How often do you delay a clean solution in favour of a quick workaround? (1-5 scale)
  • 5.How confident are you in making changes to the most debt-heavy areas? (1-5 scale)

Interpreting Results

0-15%Low burden
15-30%Moderate burden
30-50%High burden
50%+Critical burden

Average results from surveys across 12+ engineering organisations show a mean of 31%. Anything above 40% warrants immediate leadership escalation.

Recommended tools: Google Forms (free), Typeform, or a custom Notion survey. Run quarterly to track trends. Anonymise responses to get honest answers. Share aggregated results back to the team to build trust in the process.

2. Static Analysis and Code Quality Tools

Static analysis gives you objective, repeatable metrics that are harder to dismiss than survey results. These tools scan your codebase and produce quantified debt scores, duplication percentages, complexity ratings, and test coverage gaps.

SonarQube

Open source / commercial

Technical debt in days, code smells, security hotspots, coverage gaps. Self-hosted or cloud.

CodeClimate

Commercial SaaS

Maintainability scores, duplication detection, hotspot identification. Integrates with GitHub PRs.

CAST Highlight

Commercial

Software composition analysis, portfolio-level debt scores, cloud readiness. Best for enterprise portfolios.

Key Metrics to Track

  • Cyclomatic complexity per module (target: below 10 per function)
  • Code duplication percentage (target: below 5%)
  • Test coverage (target: above 70% for business-critical paths)
  • Estimated remediation time in developer-days
  • Number of known security vulnerabilities by severity
  • Dependency health score (outdated packages, abandoned libraries)

Turning Scores into Dollar Costs

SonarQube estimates debt in hours. Multiply by your average hourly rate to get a dollar figure. For a tool reporting 2,400 hours of debt at $65/hour (blended rate), that is $156,000 in remediation cost. This is the one-time fix cost, not the ongoing drag. The ongoing drag is captured by the developer survey percentage multiplied by annual payroll.

Remediation cost = tool_hours x hourly_rate

Annual drag = (survey_pct / 100) x total_payroll

Total debt burden = remediation + (annual_drag x 3)

3. Cycle Time and Velocity Analysis

Cycle time measures how long it takes a piece of work to move from started to deployed. High technical debt is one of the primary causes of cycle time inflation. Comparing cycle time across teams or over time reveals the velocity cost of debt without requiring engineers to estimate anything subjectively.

What to Measure

  • Cycle time per ticket type (bug vs feature vs refactor)
  • Deployment frequency (DORA metric)
  • Change failure rate (percentage of deployments causing incidents)
  • Time to restore service after incident
  • Lead time from commit to production
  • Build and test pipeline duration trends over time

Tools for Cycle Time Analysis

  • LinearB - Engineering metrics with debt correlation analysis
  • Jellyfish - Engineering ROI platform with sprint analysis
  • Sleuth - DORA metrics and deployment tracking
  • Jira / Linear - Raw cycle time data from your existing ticket system
  • GitHub / GitLab insights - Lead time and deployment frequency natively

4. Incident Post-Mortem Analysis

Every production incident has a root cause. A structured post-mortem process that tags root causes against a taxonomy allows you to calculate the exact cost of debt-driven incidents over time. DORA research finds 65% of incidents trace back to technical debt in some form.

Architectural debt

Tightly coupled services causing cascading failures, missing circuit breakers, synchronous calls that should be async

Dependency debt

Outdated libraries with known vulnerabilities, abandoned packages requiring forks, version conflicts blocking upgrades

Test coverage debt

Missing integration tests catching regressions too late, flaky tests masking real failures, no load testing for critical paths

Recommended Measurement Framework

Combine all four methods for a credible, multi-dimensional picture of debt that leadership cannot dismiss. Run this process quarterly.

Week 1

Run developer survey. Calculate average debt percentage. Identify top 5 problem areas by team vote.

Week 2

Run SonarQube or CodeClimate scan on all services. Export debt estimate in hours. Convert to dollars at blended hourly rate.

Week 3

Pull cycle time data for last 90 days from Jira or Linear. Calculate average cycle time for features vs debt-heavy modules.

Week 4

Review last 12 months of incident post-mortems. Tag each root cause. Calculate total incident cost attributable to debt categories.

Synthesis

Feed survey percentage into this calculator. Cross-reference with static analysis hours and incident costs. Present combined view to leadership.

Run the CalculatorStrategies to Reduce DebtPitch to Leadership