FG-0212 Reversibility Guarantee
Description
Before walking through any door, verify the handle works from the other side. Every action that modifies shared state, infrastructure, or production systems must have a tested rollback path before execution. The goal is speed with confidence, not caution for its own sake. Teams that can reverse any action move faster than teams that must get every action right the first time, because no team gets every action right the first time.
Implementation
Before any state-modifying operation, identify the rollback mechanism: branch, snapshot, config backup, infrastructure state file. Test the rollback path at least once before relying on it. Document the rollback steps alongside the execution steps. Make 'what is my undo?' the first question in any planning session, not the last.
Success Indicators
- Every deployment has a tested rollback procedure
- Team members ask 'what is the undo?' before executing, not after failing
- Recovery from any failed change takes minutes, not hours
- Experiments are attempted more frequently because failure cost is low
Failure Modes
- Rollback procedures that exist but have never been tested, discovered to be broken during an actual incident
- Over-caution: requiring rollback plans for trivially reversible actions, slowing velocity without adding safety
- Assuming version control covers everything, missing database state, external service configuration, or infrastructure changes that source control does not track
- One-way doors disguised as two-way doors: actions that appear reversible but have hidden side effects like overwriting upstream state or dropping data
Sub-Methods 3
Test rollback procedures by actually executing them. A backup file that exists is not the same as a backup file that restores. A branch that was created is not the same as a branch that merges cleanly. Run the full round-trip: create state, back up, modify, restore, verify state matches original.
Classify actions as one-way or two-way before executing. Two-way doors are reversible: editing files, creating branches, deploying behind feature flags. One-way doors are irreversible or costly to reverse: force pushing, dropping database tables, sending external communications, deleting cloud resources. One-way doors require explicit human approval and a documented justification.
Before executing any operation, assess how many systems, users, or processes will be affected if it fails. Local changes to a single file have a small blast radius. Schema migrations that affect shared databases have a large blast radius. The reversibility guarantee scales with blast radius: a local file edit needs version control; a production database change needs a snapshot, a tested rollback script, and a human watching.