Resolving technical debts in software architecture
summary
Shows concrete inspections and refactorings on real codebases: bytecode visualization with Sotograph to map packages into modules, find layer violations and a 5,270-class cycle, and quantify systems (examples: 3M, 7M, 9M lines of Java; 1,700 vs claimed nine components). Recommends actionable rules—remove cycles, enforce pattern consistency, apply small refactorings (Scout rule) and request targeted budgeted rewrites—and reports a modularity maturity index to grade whether maintenance costs stay low.
AI-written summary · about
chapters (10)
- 0:00Introduction and background
- 3:36Understanding technical debt
- 13:15Cognitive science in software design
- 25:12Technical vs domain layering
- 32:45Big ball of mud and class cycles
- 40:08Modularity and microservices
- 45:11Pattern consistency in architecture
- 50:36Anti-patterns and helper classes
- 52:22Modularity maturity index
- 53:52Conclusion and resources
related talks
30mPrioritizing Technical Debt as if Time and Money Matters
46mManaging architectural debt in a hypergrowth context
47mHow to Fix Your Technical Debt Dilemma
43mDeliver Fast with Confidence
49mMetrics for Architects
50mGuide Refactorings With Behavioral Code Analysis
01h 07mArchitect's Guide to Managing a Code Base
49mTreat Your Code as a Crime Scene