Demystifying Technical Debt
summary
Argues technical debt is measurable as the difference between perceived and ideal effort, not a mystical monster, and traces practical responses: adopt continuous learning, aim for each commit to be 1% better, run linters like staticcheck golangci-lint revive, use code reviews, consider a short external audit, and isolate messy subsystems with an anti‑corruption layer. Cites SmartPair research that error rates spike past 400 lines per change. Emphasizes tradeoffs: some debt is acceptable, full rewrites usually fail.
AI-written summary · about
chapters (24)
- 0:00Intro
- 0:26Technical Debt Monster
- 2:03Quality / Mistakes
- 3:15Effort in Code Modification
- 4:13Effort in Understanding
- 5:08Effort in Communication
- 5:42Change in Code Modification Effort
- 6:07Change in Understanding Effort
- 6:45Change in Communication Effort
- 7:10Change in Effort
- 7:34When code is unused, does it accumulate technical debt?
- 8:11We notice mistakes
- 11:38Breakthroughs
- 12:31Borrowing
- 14:48Positive Bias in Perceived/Ideal Effort
- 15:39Negative Bias in Perceived/Ideal Effort
- 17:46Precision / Accuracy?
- 18:34Originally about "business' reflecting "code
- 19:23Rewrite???
- 20:15Continuous Learning
- 21:13Code Reviews
- 22:50Maintenance
- 23:53Acceptance
- 24:40Technical Debt is not a Monster.
related talks
34mThe Technical Debt Trap
15mThe Truth About Technical Debt
35mTechnical Debt. A guide for developers and IT managers
01h 01mThe Technical Debt Prevention Clinic
28mManaging Technical Debt at Scale
25mLiving With Technical Debt: Acknowledge It, Specify It, Reduce It
28mTechnical Debt: Why it'll ruin your software
57mPutting an end to "technical debt"