Prioritizing Technical Debt as if Time and Money Matters
summary
Argues technical debt becomes actionable by mining version control to find hotspots, combining change frequency with code health metrics to prioritize work. Shows Android platform framework base with 3 million lines and a top hotspot file of 20,000 lines where a 500-line function handle message is changed 98 times in a year and has cyclomatic complexity implying ~108 unit tests. Introduces open source tools codemat and codesyn and uses x‑ray function-level blame to pick small, safe refactor targets from huge systems.
AI-written summary · about
chapters (20)
- 0:00Intro
- 1:53Increasing Complexity: consequences and impact
- 3:49QUANTIFYING TECHNICAL DEBT?
- 6:20What is a Behavioral Code Analysis?
- 7:15Version-Control - A Behavioral Data Source
- 8:14Case Study: Android
- 10:57Complexity Explained: is code quality really a thing?
- 11:54Healthy Code: Beyond a Single Metric
- 14:24Code health: context matters
- 15:14Back to Android: Actionable Insights?
- 16:34X-Ray of ActivityManager Service.java
- 18:20Why You Don't Have To Fix All Technical Debt
- 20:39What Is Legacy Code?
- 21:03The Technical Debt That Wasn't
- 23:13Case Study: ASP.NET MVC Core
- 23:42Software Evolution: power laws are everywhere
- 24:20Case Study: Off-Boarding
- 26:02Mitigate off-boarding risks
- 26:52There's More to Code Complexity than Code
- 27:13Tooling: Try it on your own Code
related talks
20mPrioritizing Technical Debt as if Time and Money Matters
32mPrioritizing Technical Debt as if Time and Money Matters
39mArch. App: Prioritizing Technical Debt as if Time and Money Matters
36mPrioritizing Technical Debt as if Time & Money Matters
45mTechnical Debt Prioritisation - Identifying & Fixing Highest ROI Issues
36mNo More ‘Someone Else’s Problem’: Tackling Tech Debt at Scale
48mTechnical Debt Trap
11mRefactoring: Managing technical debt before it blows up in your face