A Bluffer's Guide to Technical Debt for Other People
summary
Argues that technical debt behaves like a portfolio of short call options rather than linear principal plus interest, so risk spikes when many options get called at once. Recommends measuring cost of delay, mapping components on a hurricane map to spot hotspots (one component example shows ~500 days to fix), and using hotspot research and static tools (Sonar) plus hedges: preemptive clean-ups, improved dev environment, and targeted refactors. Focuses on dynamic risk management and prioritizing where debt actually blocks delivery.
AI-written summary · about
chapters (8)
- 0:00Introduction
- 1:49What is technical debt
- 12:47Problems with debt metaphor
- 21:29Cost of delay explained
- 26:26Short call options and risk
- 31:01Product owner’s role
- 38:54Dynamic risk management
- 40:59Summary and metaphor
related talks
35mTechnical Debt. A guide for developers and IT managers
28mManaging Technical Debt at Scale
25mDemystifying Technical Debt
15mThe Truth About Technical Debt
36mPrioritizing Technical Debt as if Time & Money Matters
25mLiving With Technical Debt: Acknowledge It, Specify It, Reduce It
30mPrioritizing Technical Debt as if Time and Money Matters
45mA developer always pays his debts