tjboudreaux/thinking-occams-razor

Occam's Razor

Overview

Occam's Razor states: among competing hypotheses that fit the evidence equally well, prefer the one with the fewest assumptions. This skill operationalizes that principle for debugging: test the simplest hypothesis first, and escalate to complex explanations only when evidence forces it.

The skill has a trigger-shrink gate: if the simplest hypothesis can be tested in one step, just test it — don't run the full enumeration-and-scoring procedure. Reserve the full procedure for situations where multiple hypotheses genuinely compete and the simplest is not obviously testable.

Core Principle: "Everything should be made as simple as possible, but no simpler." — Einstein

When to Use

• Multiple hypotheses could explain a bug and the simplest is NOT obviously testable in one step
• You're about to investigate a complex hypothesis without first testing a simpler one
• Architecture or design decisions where several approaches are viable and differ in complexity
• Root cause analysis where several causes seem plausible

Decision flow:

Multiple explanations exist?
  → No → Use the available explanation
  → Yes → Can the simplest be tested in one step?
      → Yes → JUST TEST IT (trigger-shrink — skip full procedure)
      → No → Do they explain the evidence equally well?
          → No → Prefer the better explanation
          → Yes → RUN FULL OCCAM'S RAZOR PROCEDURE

When NOT to Use

• Evidence already points to a specific cause. Follow the evidence; don't downgrade to a "simpler" hypothesis it contradicts.
• The domain is irreducibly complex (distributed consensus, concurrency, security threat models). The simplest model is wrong; don't oversimplify ("but no simpler").
• Only one plausible explanation exists. There's nothing to compare — just test it.
• "Simple" would mean ignoring a known interaction or skipping a load-bearing safeguard. Local simplicity that creates systemic risk isn't parsimony.
• The trigger check resolves it. If you can test the simplest hypothesis in one step and it's confirmed, you're done — don't enumerate for completeness.

Trigger Card

Before running the full enumeration-and-scoring procedure, ask one question: "Can I test the simplest hypothesis in one step?"

1. Identify the simplest hypothesis — the one with the fewest assumptions that still explains the evidence.
2. Can you test it in one step? → Yes → Just test it. If confirmed, report and stop. If refuted, move to the next simplest.
3. If it can't be tested in one step → run the full Occam's Razor procedure (enumerate, count assumptions, verify explanatory power, test in order).

If evidence already points to a specific cause, follow the evidence — don't downgrade to a "simpler" hypothesis it contradicts. For irreducibly complex domains (distributed consensus, concurrency), the simplest model is wrong.

Procedure

Trigger Check (Fast Path)

Before running the full procedure, ask: "Can I test the simplest hypothesis in one step?"

• Yes → Test it. If confirmed, report and stop. If falsified, move to the next simplest.
• No → The simplest hypothesis requires non-trivial investigation → run the full procedure below.

Full Procedure: When the Trigger Check Doesn't Resolve

Step 1: Enumerate Competing Hypotheses

List all plausible explanations for the observed behavior:

Bug: Users intermittently can't log in

Hypotheses:
A. Session token expiration edge case
B. Race condition in auth service
C. Database connection pool exhaustion
D. Complex interaction between CDN cache, load balancer, and session service

Step 2: Count Assumptions per Hypothesis

| Hypothesis | Assumptions | |------------|-------------| | A. Token expiration | 1. Token validation has an edge case | | B. Race condition | 1. Concurrent requests possible, 2. Shared mutable state exists | | C. DB pool exhaustion | 1. Pool is undersized, 2. Connections are leaking | | D. Complex interaction | 1. CDN caches auth, 2. LB sticky sessions fail, 3. Session sync delayed |

Count each independent assumption: +1 per assumption, +1 per component involved, +2 per external dependency, +2 for timing-dependent behavior, +3 for rare conditions, +5 for "perfect storm" scenarios.

Step 3: Verify Explanatory Power

Ensure simpler hypotheses actually explain the evidence:

Evidence: Failures correlate with high traffic periods
Hypothesis A (token edge case): Doesn't explain traffic correlation ✗
Hypothesis C (DB pool exhaustion): Explains traffic correlation ✓ — fewer assumptions than D
→ PREFERRED by Occam's Razor

Step 4: Test in Order of Fewest Assumptions

Investigate hypotheses from fewest to most assumptions. Do not skip to complex hypotheses until simple ones are ruled out.

Step 5: Escalate Complexity Only When Evidence Forces It

When simple explanations are ruled out with evidence, move to more complex ones. Never escalate on intuition alone.

Output Contract

A completed Occam's Razor analysis produces:

1. Trigger Check Result — whether the simplest hypothesis was testable in one step
2. Hypothesis Ranking — ordered by assumption count, with each hypothesis' assumptions listed
3. Explanatory Power Check — which hypotheses fit the evidence
4. Test Order and Results — which hypotheses were tested, in what order, and the outcome
5. Conclusion — the confirmed hypothesis (or the next to test if unresolved)

For trigger-shrink cases, the output may be a single line: "Tested simplest hypothesis X — confirmed/refuted."

Anti-Patterns

| Anti-Pattern | Symptom | Correction | |---|---|---| | Oversimplifying irreducible domains | Applying "simplest" to distributed consensus or security models | "But no simpler" — respect domain complexity | | Complexity bias | Assuming complex = sophisticated, testing complex hypotheses first | Test fewest-assumption hypotheses first, always | | Trigger inflation | Running the full enumeration for a one-step test | If the simplest is one-step testable, just test it | | Ignoring explanatory power | Choosing the simplest hypothesis that doesn't fit the evidence | Fewer assumptions doesn't beat not fitting the data | | Local simplicity, systemic risk | Choosing a simple local fix that creates fragility elsewhere | Prefer systemic simplicity over local simplicity | | Ritualistic assumption counting | Spending more time counting assumptions than testing | The point is prioritization, not precision; rough count is enough |