Technical Debt - Why the Term Causes More Confusion than Clarity
summary
Argues that technical debt must be turned into measurable business KPIs: cites a 1,000‑developer/executive study where >40% time is maintenance, shows a custom tool detangle that maps commits to issue IDs, computes maintenance effort, an “interest rate” (extra work per new feature), and surfaces hotspots like feature coupling and knowledge islands. Demonstrates root‑cause metrics (code complexity, test gaps, ownership skew), recommends separate refactor tickets and time‑based forecasts so decisions and ROI are provable.
AI-written summary · about
chapters (18)
- 0:00Introduction to talk
- 0:41Problems with technical debt term
- 5:16About Cape of Good Code
- 7:27Why developers sound unconvincing
- 10:40Martin Fowler’s technical debt quadrant
- 13:16Why the financial metaphor fails
- 17:57Linking debt to business outcomes
- 20:45Measuring symptoms of technical debt
- 23:17Data sources for analysis
- 26:49Key performance indicators
- 29:18Identifying hot spots
- 31:09Root causes of technical debt
- 33:14Architecture quality metrics
- 35:02Case study: Corona Warn App
- 36:28Knowledge distribution analysis
- 39:17Showing the payoff of refactoring
- 40:43Practical recommendations
- 41:28Summary and Q&A
related talks
48mTechnical Debt Trap
53mThe Technical Debt Trap
01h 36mWorkshop: Tackling Technical Debt: An Analytical Approach
35mTechnical Debt: When Interest Eats Your Code
01h 01mThe Technical Debt Prevention Clinic
46mStop calling it technical debt and listen to your engineers
47mToxic Code: Technical Debt Analytics
36mPrioritizing Technical Debt as if Time & Money Matters