The Case for Technical Excellence
summary
Argues that continuous technical excellence materially increases agility by lowering cost of change, and that technical debt is an effect caused by neglect rather than an intrinsic label; claims features are not separate from engineering — features are made of software — so prioritizing “business value” without time-boxed experiments just yields estimates, not facts. Uses Grady Booch’s cost-of-change definition of architecture, the boat-and-holes metaphor for neglect, and an observation that developers often spend roughly one hour a day on true value work.
AI-written summary · about
chapters (14)
- 0:00Introduction and setup
- 1:10Technical excellence in agile
- 4:18Business goals vs technical work
- 8:52Feature work is technical work
- 11:42Defining business value
- 15:34Prioritizing by business value
- 18:24Architecture and cost of change
- 21:17Technical debt vs neglect
- 27:56Metaphors in software
- 34:59Technical debt as borrowing
- 39:09Unmanaged technical debt
- 40:55Demand and failure demand
- 43:44Developer autonomy and ownership
- 45:31Q&A
related talks
41mA Defence of Technical Excellence
28mManaging Technical Debt at Scale
27mTechnical Excellence: Why does it not stick even now?
51mA Defence of Technical Excellence
57mPutting an end to "technical debt"
38mPractices for Effective Continuous Software Architecture
28mTechnical Debt: Why it'll ruin your software
34mThe Technical Debt Trap