Comparisons
Pairs engineers genuinely confuse — goal and implementation, MVP and bad prototype, prototype and spike, reversible and irreversible. Neither column wins; what decides is the problem. Each record leads with the confusion, because the confusion is what it costs.
Reversible vs irreversible decisions
All decisions get the same amount of deliberation — three meetings for a library that could be swapped in a day, and a slack message for the identifier scheme that will be in every URL forever. The cost is two-sided: reversible decisions eat time that irreversible ones needed, and irreversible ones are made by default. The sorting question is "what would it cost to change this in six months?", and the honest complication is that reversibility is not fixed: a reversible choice becomes irreversible once enough code and data depend on it, which is why the journal notes when to revisit.
Decide fast, note it in the journal, move on. Which library, which folder layout, which of two equivalent frameworks.
Deliberate in proportion: the data model for money, the tenancy boundary, the public API, the identifier format, the vendor the data lives with.
| Aspect | Reversible — can be undone in about the time it took to make, without data loss or a public contract broken | Irreversible — undoing it costs a migration, a customer-facing change or a rewrite |
|---|---|---|
| Cost to undo | About the cost to make | A migration, a rewrite, an announcement |
| Deliberation deserved | Minutes; a note | Days; alternatives and evidence |
| Examples | HTTP library, folder layout, test runner | Money data model, primary keys, public API shape, where the data lives |
| Strategy under uncertainty | Pick one and learn | Delay until the last responsible moment, then prototype the risky part |
| Changes over time | Becomes irreversible once depended on | Rarely becomes reversible |
| Typical mistake | Three meetings | Made by default in a scaffold |