Refactoring: Managing technical debt before it blows up in your face
summary
Provides a concrete prioritization framework: score technical debt by developer and customer impact, how fast it’s spreading and surface area plus confidence in the estimate, then rank in a spreadsheet. Gives numbers and outcomes: build times from 40 to 30 minutes saves roughly 1,000 minutes of dev time daily in a 100‑dev org, and a data‑model refactor cuts defects from 10 bugs a month to one every 2–3 months. Suggests pragmatic mitigations like eslint rules, pre‑commit checks and release checklist steps when the full fix must wait.
AI-written summary · about
chapters (4)
- 0:00Start
- 5:14How will this work impact your developers?
- 6:47How fast is it getting worse?
- 7:27Can you stop the bleeding?
related talks
45mTechnical Debt Prioritisation - Identifying & Fixing Highest ROI Issues
36mPrioritizing Technical Debt as if Time & Money Matters
17mHow to deal with technical debt in fast-paced environment
10mPractical tech-debt prioritization
01h 36mWorkshop: Tackling Technical Debt: An Analytical Approach
30mPrioritizing Technical Debt as if Time and Money Matters
28mManaging Technical Debt at Scale
20mPrioritizing Technical Debt as if Time and Money Matters