Reversible Decisions for Better Software Design
summary
Claim: making decisions reversible keeps long-lived projects fast to change by containing coupling and preserving options. Practical moves include creating a demilitarized zone between domain and outside systems, using feature flags plus test-driven development and static analysis as automatic guardrails, adding anti‑corruption layers and clear bounded contexts, and working in many more much smaller steps with automated refactor tools and approval tests. AI helps evaluate impact and suggest step sequences but needs tests and guardrails to avoid large, hard-to-review edits.
AI-written summary · about
chapters (17)
- 0:00Talk overview
- 1:20Branching delays reversible decisions
- 2:48Hard-to-reverse changes
- 4:34Reversible vs irreversible decisions
- 8:45Coupling and cohesion
- 10:11Happy zone and DMZ
- 12:58Containing damage with error boundaries
- 16:09SOLID and CUPID for reversibility
- 20:46DDD and bounded contexts
- 21:48Options value of reversibility
- 24:17Smaller development steps
- 27:45Feedback loops for safer changes
- 28:49TDD as feedback
- 31:35Refactoring for reversibility
- 35:28AI in reversible design
- 41:34Summary
- 43:01Q&A
related talks
01h 00mDecision Dials
47mMaking architecture decisions, the Agile Way
40mEvolutionary Architecture - The art of making decisions
45mGeneric or Specific? Making Sensible Software Design Decisions
41mSimplicity as a Superpower
35mRedundancy Driven Development - Navigating disruptive codebase changes.
36mThe 7 Battles of Software Architecture: How to Protect Your Project!
25mThinking Architecturally