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.
Thought experiment vs experiment
Reasoning is used where observation was needed ("the database will handle that") and observation is used where reasoning would have been faster (a load test to discover that the design has no cache invalidation at all). The cost of the first is a confident design that fails on the provider's actual behaviour; the cost of the second is a day of infrastructure to learn what five minutes on paper would have shown. The rule of thumb is that the design is the thought experiment's domain and the world is the experiment's — and that the experiment still needs a prediction, or it is a demo.
Before building, and for questions where the design is the variable — does this state machine have an illegal transition, does this propagate a price change into old orders.
When the answer depends on how a real component behaves — the provider on timeout, the database under two concurrent updates — and no amount of reasoning replaces the observation.
| Aspect | Thought experiment — walk the design by hand: one request, one failure, two requests at once | Experiment — run the thing, with a prediction written first, and observe |
|---|---|---|
| Variable | The design | The world |
| Cost | Minutes on paper | Hours to days of setup |
| Answers | "Does the design hold?" | "What does the component actually do?" |
| Example | Trace a price change through cart, order, refund | Two concurrent decrements on one stock row |
| Requires | Honesty | A prediction written before the run |
| Mistake | Trusting reasoning about a provider's behaviour | Building infrastructure to learn what paper would show |