Variability, The Second Hardest Problem ...
summary
Variability is inevitable and lives in the messy design “squiggle,” driven by choices of language, framework, platform, APIs and integrations, and it creates cognitive load and cross-team coordination overhead. Practical response is to split big choices into small, tested decisions, pick fracture planes (functional split, delivery timing, codebase location, flow-unblocking decisions), and validate quickly by implementing: TDD/BDD, feature toggles, walking skeletons, CI/CD and production tests tied to DORA metrics. This reduces risk, shrinks the cone of uncertainty and fosters trust; fast and wrong beats slow and “correct” when feedback loops are real.
AI-written summary · about
chapters (7)
- 0:00Introduction and context
- 3:41The design thinking squiggle
- 10:20Understanding architectural variability
- 24:03Why variability hurts
- 28:16Managing architectural variability
- 37:40Succeeding with variability
- 45:43Conclusion and Q&A
related talks
41mBeyond "it depends" - How much architectural work do we need?
27mDesigning Even Larger (JavaScript) Applications
44mReversible Decisions for Better Software Design
58mDon't Walk Away From Complexity, Run
28mAvoid overengineering & big ball of mud- 7 lessons for maintaining the balance
26mAccept Complexity or Reject It? — Reflections Facing a Monolith Raised Alongside Business Growth
56mKicking the Complexity Habit
50mSoftware Is Details