Technical debt isn't technical
summary
Claim: most “technical debt” is not poor coding but weak abstractions born from incomplete domain modeling, worsened by organizational inertia and broken communication. Evidence: an eQuest horse-product example and NRK TV “what is a TV show” modeling show classification failures; refactoring catalogues (low‑level refactorings) and rewrites without closing the understanding gap fail; Conway’s law predicts system mirrors team structure so organizational change is often required. Practical takeaway: fix the model and collaboration first, then refactor; otherwise rewrites recreate the same debt.
AI-written summary · about
chapters (16)
- 0:00Start
- 0:54WHAT IS TECHNICAL DEBT?
- 2:37SURVIVAL OF THE FITTEST?
- 10:02WHAT IS THE NAME OF THE TOOL WE USE TO CONTAIN AND CONQUER COMPLEXITY?
- 10:16WHAT IS THE NAME OF THE TOOL WE USE TO CREATE AND COMPOUND COMPLEXITY?
- 10:32MODELLING IS DEFINING WHAT THE PROBLEM DOMAIN IS
- 11:42REFACTORING!
- 17:21BUGS!
- 26:21THE CLASSICAL THEORY OF CATEGORIZATION IS BASED ON PROPERTIES
- 26:57WHAT DOES A BIRD LOOK LIKE?
- 28:14ELEANOR ROSCH PROTOTYPE THEORY
- 31:55HOW AGILE IS THE ORGANIZATION?
- 33:15INVERSE CONWAY MANEUVER REORGANIZE TO DRIVE ARCHITECTURAL CHANGE
- 34:10SYSTEM ARCHITECTURE IS ENTERPRISE ARCHITECTURE AND VICE VERSA
- 35:51TECHNICAL WORK IS PUZZLE SOLVING
- 36:34GREATEST EXPLANATION POWER?
related talks
34mThe Technical Debt Trap
28mTechnical Debt: Why it'll ruin your software
35mTechnical Debt. A guide for developers and IT managers
57mPutting an end to "technical debt"
35mTechnical Debt: When Interest Eats Your Code
01h 01mThe Technical Debt Prevention Clinic
18mTechnical Debt: How to Communicate to Teams, Beyond the Tech
45mTechnical Debt: Taking back control when it's already messed up