Technical debt is frequently discussed but rarely measured. Teams know it exists — they feel it in every feature that takes three times longer than expected — but struggle to articulate the cost in terms that matter to business stakeholders. The result is either premature refactoring that delivers no visible value, or perpetual deferral until the system becomes unmaintainable.
Debt has compound interest
A shortcut taken in month two does not stay a local problem. Other code is written around it. New developers learn the workaround as if it were the pattern. Tests are written to accommodate the quirk. By month twelve, removing the original shortcut requires changing forty files and updating three deployment scripts. The interest rate on technical debt is not linear — it compounds.
The most expensive technical debt is the kind that looks like it is working. It ships features, passes tests, and quietly makes every future change more expensive.
A practical measurement framework
We track four metrics to make debt visible: change failure rate (how often deployments cause incidents), lead time for changes (how long from commit to production), time-to-onboard (how long until a new developer ships independently), and unplanned work ratio (what percentage of sprints are consumed by firefighting). When these metrics trend in the wrong direction, the debt is materialising.
- Track change failure rate across deployments
- Measure lead time from commit to production
- Monitor new developer onboarding duration
- Calculate the ratio of planned vs. unplanned work