Occam's Razor
The simplest explanation is usually correct.
Tiny Summary
Occam's Razor: "The simplest explanation is usually the correct one." When debugging or designing, prefer simple solutions over complex ones.
The Principle
Choose hypotheses with fewest assumptions. Not "simplest is always right" but "start simple, add complexity only when needed."
In Debugging
Bug: API returning 500 errors
Complex theory: Race condition in distributed cache, network partition, cosmic ray bit flip
Simple theory: Database connection pool exhausted, missing environment variable, typo in config
Occam's Razor: Check simple things first.
In Architecture
Problem: Store user sessions
Complex: Distributed Redis cluster with Sentinel, session replication across regions, custom consistency protocol
Simple: Single Redis instance, sessions in database, or signed JWT tokens (no storage)
Occam's Razor: Start simple, scale when needed.
In Code
Check if number is even: return n % 2 == 0; (simple) vs bitwise operations + redundant checks (complex). Simpler is better.
When to Violate
Known requirements demand complexity: Global scale → distributed systems. Financial data → consistency guarantees. High security → cryptographic protocols. But beware premature optimization.
Key Insights
Complex solutions are often wrong AND hard to debug. Simple solutions are easier to understand, maintain, test. Add complexity incrementally when needed. Occam's Razor means "no unnecessary complexity," not "simplistic." Related: KISS, YAGNI, "Simplest Thing That Could Possibly Work."