A Crystal Ball to Prioritize Technical Debt
summary
Claims that version‑control behavior pinpoints where technical debt matters, not raw static metrics; shows a static tool reporting “4,000 years” of debt on a legacy codebase and says that’s useless without activity data. Demonstrates hotspots from commit frequency × complexity, drills huge files (gc.cpp ≈47,000 LOC) with an x‑ray to find a 342‑line hotspot function, and tracks complexity trends over time as early warnings. Uses Codemap/CodeScene examples and links organizational signals (diffusion of responsibility, Conway’s Law) to actionable refactor and team changes.
AI-written summary · about
chapters (18)
- 0:00Intro
- 0:46Questioning Technical Debt
- 2:41Interest Rate Is A Function Of Time
- 3:02All Technical Debt Isn't Equal
- 5:59h List: Information to Prioritize Technical Debt
- 7:39on-Control - A Behavioral Data Source
- 12:59Why Hotspots Work
- 14:51Case Study: The .NET Core Runtime
- 16:06gc.cpp - A Capacity Test of GitHub
- 17:50Function-Level Hotspots in gc.cpp
- 18:48Normalization of Deviance
- 23:20Supervise your complexity Trends
- 25:48poling: Try it on your own Code
- 27:43Process Loss
- 29:05Diffusion of Responsibility
- 31:04are Team Coordination fusion of Responsibility
- 34:16Measuring Conway's Law
- 38:04Decisions Influenced By Data
related talks
25mDemystifying Technical Debt
11mRefactoring: Managing technical debt before it blows up in your face
56mCode & Homicide: What Software Devs (..) from Offender Profiling
28mManaging Technical Debt at Scale
01h 01mThe Technical Debt Prevention Clinic
39mThe cash value of technical debt - How to scare your boss into doing the right thing
31mDealing with Technical Debt
40mTreat Your Code as a Crime Scene