Glossary
By Glue Team
Measuring technical debt is the practice of quantifying the cost and impact of shortcuts, legacy code, and architectural compromises in concrete terms: hours lost, bugs prevented by fixing it, and velocity gained through remediation. Without measurement, technical debt remains invisible and unfundable.
You can't manage what you don't measure. Most teams describe tech debt subjectively: "This module is a nightmare" or "Our codebase is legacy and slow." Leadership hears these complaints but doesn't fund solutions because the cost is undefined.
Measured technical debt is fundable debt: "This module consumes 10 hours/week of refactoring work = $480K/year cost. Rebuilding it takes 6 weeks and saves 8 hours/week going forward = ROI in 9 months."
Engineering time tax: Track time spent refactoring, fixing related bugs, and reworking due to unclear code. This is the direct cost.
Example: If a payment module causes 2 hours of refactoring and 3 hours of bug fixes per week across the team, that's 260 hours/year × $150/hour = $39K annual tax.
Velocity drag: Compare velocity in legacy code vs. new code. If new features take 30% longer in the legacy module, multiply excess hours by engineer cost.
Incident correlation: Measure how much operational time legacy code consumes. If 40% of on-call incidents touch the legacy payment module, multiply incident cost by 40%.
New hire ramp time: If it takes 8 weeks to onboard in a chaotic area vs. 4 weeks in well-structured code, the difference is an onboarding cost premium.
Test coverage gaps: Code with < 50% coverage produces 5x more production bugs. Multiply the extra bugs by cost per bug (investigation, fix, customer impact).
Raw metrics are worthless without context:
| Metric | Raw Data | Business Translation |
|---|---|---|
| Cyclomatic complexity > 15 | 8 functions | Expect 2-3 additional bugs per quarter in these functions; fix costs 3x normal |
| Test coverage 30% | Module A | Estimate 8-10 escaped bugs/year; remediation cost: 3 weeks refactoring + testing |
| Code churn 45% | Service B | Indicates unclear requirements; recommend design review before next feature |
| 4-week onboarding vs. 2-week target | Team velocity | Assign 2 weeks refactoring to reduce onboarding debt; ROI: 4x faster ramp for next 3 hires |
Effective measurement lives in dashboards teams see daily:
When engineers and leadership see that refactoring pays for itself in 9 months, funding becomes a straightforward business decision.
Q: How do we know if tech debt measurement is accurate? A: Validate by comparing estimates to actuals. If you estimate "fixing module X saves 200 hours/year" and after fixing it you observe 220 hours saved, your model is accurate.
Q: Should we measure all tech debt or just high-priority areas? A: Start with high-impact areas: code that changes frequently, causes most incidents, or blocks new features. Measure comprehensively after initial wins prove value.
Q: How often should we re-measure? A: Quarterly at minimum. As you fix debt, remaining debt becomes more visible and new measurement opportunities emerge.
Keep reading
