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.
Happy path vs failure path
"Happy path first" is heard as "happy path only", and the failure pass never happens, so the store ships with a checkout that double-charges on a double click. The opposite confusion is designing the retry logic before an order can be created, which is guessing at failures of a thing that does not exist. The order is contested honestly: the strongest form of failure-first is that some systems exist to handle failure — a payment reconciler, a job scheduler — and their happy path is trivial, so the failure model is the design and should come first. For a store, the happy path first is right because it is the thing the failures are failures *of*; the discipline is that "second" means the same week.
First, on most product work: it makes the failures visible and gives you something to inject them against.
Second — and immediately after, not "later": each failure asked at each step, answered with prevent, detect, retry or accept.
| Aspect | Happy path — the workflow when every step succeeds: browse, add, pay, confirm | Failure path — what happens when a step does not: declined, timeout, duplicate, crash mid-way |
|---|---|---|
| Question | "What happens when it works?" | "What happens when this step does not?" |
| Produces | The workflow and the first slices | Requirements the happy path could not show |
| Test shape | A scenario with an expected result | A failure injected against a working path |
| When first is right | Most product features | Systems whose job is handling failure |
| Cost of skipping | Nothing to inject failures against | The first real day of traffic |
| Sign of the mistake | "We will handle errors later" — and later never comes | Retry logic for an order that cannot yet be created |