What is Technical Debt?
Technical debt is the implied cost of future rework caused by choosing an expedient solution now instead of a better approach that would take longer. First coined by Ward Cunningham in 1992, technical debt has become one of the most important concepts in software engineering economics.
Like financial debt, technical debt accrues interest. Every shortcut, every "we'll fix it later," every copy-pasted function adds to the principal. The interest comes in the form of slower development velocity, more bugs, longer onboarding times for new engineers, and increased fragility of the system.
Technical debt exists on a spectrum from deliberate ("we know this is a shortcut but ship it anyway") to accidental ("we didn't realize this was a bad pattern until later"). Both types compound over time. Organizations that don't actively measure and manage their technical debt risk reaching what Richard Ewing calls the Technical Insolvency Date — the specific quarter when maintenance costs consume 100% of engineering capacity.
Why It Matters
Most engineering teams track technical debt qualitatively ("we have some debt") rather than quantitatively ("our maintenance burden is 47% of total engineering hours and growing 3% per quarter"). This qualitative approach lets debt accumulate invisibly until it becomes a financial crisis.
For CFOs and board members, technical debt is invisible unless it's quantified in dollar terms. An engineering team reporting "we need to pay down tech debt" gets deprioritized. An engineering team reporting "we're spending $2.3M annually maintaining code that generates zero revenue, and that number grows by $180K per quarter" gets immediate attention.
The Product Debt Index (PDI) calculator at richardewing.io/tools/pdi translates technical debt into financial terms that executives and boards can act on.
How to Measure
1. **Maintenance Percentage**: Track what percentage of engineering time goes to bugs, maintenance, and keeping-the-lights-on work vs. new feature development.
2. **Code Quality Score**: Use tools like SonarQube, CodeClimate, or custom dashboards to measure cyclomatic complexity, code duplication, and test coverage.
3. **DORA Metrics**: Deployment frequency, lead time for changes, change failure rate, and mean time to recovery provide proxies for debt burden.
4. **Dollar Value**: Multiply maintenance hours × fully-loaded engineer cost to express debt in financial terms.
5. **Growth Rate**: Track the maintenance percentage quarter-over-quarter. If it's increasing, you're accumulating debt faster than you're paying it down.
Frequently Asked Questions
What is technical debt in simple terms?
Technical debt is the extra work you create for yourself later by taking shortcuts in code today. Like credit card debt, it accrues interest — the longer you leave it, the more expensive it becomes to fix.
How do you measure technical debt?
The best approach is measuring maintenance percentage (% of engineering time spent on bugs and maintenance vs. new features) and converting it to dollar terms. Use the Product Debt Index calculator at richardewing.io/tools/pdi for a quantitative assessment.
What causes technical debt?
Common causes include tight deadlines forcing shortcuts, lack of automated testing, poor documentation, outdated dependencies, copy-paste coding, insufficient code reviews, and organizational pressure to ship features without proper architecture.
How much technical debt is acceptable?
A maintenance percentage below 30% is healthy. Between 30-50% is concerning. Above 50% means more than half of your engineering capacity goes to maintenance rather than innovation. Above 70% is near the Technical Insolvency Date.
Free Tools
Related Terms
Free Tool
Calculate your technical debt in dollar terms
Use the free Product Debt Index diagnostic to put numbers behind your technical debt challenges.
Try Product Debt Index Free →Need Expert Help?
Richard Ewing is a Product Economist and AI Capital Auditor. He helps companies translate technical complexity into financial clarity.
Book Advisory Call →