Best for
- Bugs that 'cannot happen' but do
- Intermittent failures nobody can pin down
- Ending the cycle of patching symptoms
What you give it
- What happened and what should have happened, with any logs or steps you have
- Access to the code, and answers about expected behaviour when asked
What you get back
- A reliable reproduction, or an honest account of why one is not possible
- The root cause named with the evidence chain that proves it
- The fix at the cause, a regression test, and a note on anything else the cause infects
How it works
- Writes down the symptom precisely, then tries to reproduce it before theorising.
- Forms hypotheses and tests the cheapest one first, keeping a log of what was ruled out.
- Narrows with evidence: logs, bisection, minimal cases — not vibes.
- Distinguishes the root cause from the place the symptom appeared.
- Fixes the cause, adds a test that fails without the fix, and checks for siblings of the same bug.
Example
You: Some customers get a blank page after paying. Support says it is random.
Result: Reproduced: it is not random — it hits accounts whose names contain a quote character, which breaks the receipt template. Fix at the escaping layer, a regression test with the hostile name, plus a list of two other templates with the same flaw.
Limits — please read
- Some bugs need data or environments only you can provide — it will name exactly what it needs.
- A fix beyond the bug's scope (a design flaw) is reported, not silently rebuilt.
- Heisenbugs may yield probability, not certainty; it reports confidence honestly.