Selling Maintainability
summary
Defines maintainability as components with few dependencies and single responsibilities, and argues that recording and reviewing architecture decision records is the lever that turns shortcuts into measurable trade-offs. Recommends estimating the effort of a repeatable feature over time to track cost of change, budgeting a fixed chunk of each sprint for tech work, and avoiding disaster-driven heroic fixes (spikes that often follow review cycles). Uses bridge and messy-room analogies and shows a German bridge map to justify rebuild vs repair.
AI-written summary · about
chapters (8)
- 0:00Introduction
- 1:52What is Maintainability
- 6:19Why do engineers care
- 10:28How to explain maintainability
- 16:43Train bridge analogy
- 19:28Evolution analogy
- 21:28Tips and tricks
- 28:58Cost of change
related talks
41mHow to write maintainable code
44mBuilding resilient frontend architecture
01h 03mLong-lived software architectures that survive decades without debt
44mDeliberate Architecture
49mCultivating Architecture
43mThinking Architecturally
27mTechnical Excellence: Why does it not stick even now?
47mMaking architecture decisions, the Agile Way