Reversibility

There are no final decisions. Because requirements, environments, and understanding all change, good design keeps important decisions reversible, so a choice that turns out wrong can be undone without rewriting everything. Avoid one-way doors where a cheaper two-way door exists.

Why it Matters

Decisions made with confidence today are routinely invalidated tomorrow. Systems that hard-wire assumptions, a vendor, a database, a protocol, into everything become brittle and expensive to change. Keeping decisions behind abstractions preserves the freedom to change course cheaply. Designing Data-Intensive Applications names this property evolvability and counts it part of maintainability: data outlives code, so systems must be built to be changed.

Signals

• A "temporary" choice that has spread so widely it can no longer be undone.
• Critical assumptions wired directly into many components.
• Dread at the thought of changing a foundational technology.

Benefits

Adaptability to changing requirements, freedom from lock-in, and the ability to defer or revise decisions as understanding improves.

Risks

Chasing reversibility everywhere adds indirection and abstraction that may never pay off; not every decision needs a two-way door, and some abstraction layers cost more than the flexibility is worth.

Tensions

Flexibility competes with simplicity and commitment: the abstraction that keeps a decision reversible is itself complexity, and at some point committing is cheaper than staying open.

Examples

Hiding a database behind a narrow interface so it can be replaced; isolating a third-party service so swapping vendors touches one component, not the whole system.