Back to all topics
software-engineering

Murphy's Law

Anything that can go wrong, will go wrong.

Tiny Summary

Murphy's Law: "Anything that can go wrong, will go wrong." A foundational principle for defensive programming, error handling, and system design.


The Law

If there's a possibility of something failing, assume it will fail—eventually, under the worst possible circumstances.


In Software

Assume failures: Network requests timeout, databases unavailable, disks fill up, users enter invalid data

Defensive programming: Don't assume API returns data → Handle null, timeouts, malformed responses. Don't trust user input → Validate, sanitize, escape everything.


Corollaries

Finagle's Law: Things fail at the worst possible time (production breaks during demo, 3am, right before launch)

Buttered Toast: Things fail in the most inconvenient way possible


Applications

Error handling: Every function can fail → Handle every error. Every external call timeouts → Set timeouts. Every parse encounters bad data → Validate.

Redundancy: Single server crashes → Add redundancy. Single database fails → Add replicas. Single datacenter offline → Multi-region.

Testing: If users can do it wrong, they will. If data can be corrupted, it will. Edge cases will hit production.


Real Examples

Space Shuttle Challenger: O-rings could fail in cold. NASA assumed "won't be that cold" → Disaster.

Cloudflare (2020): Router config could cascade. Assumed "we'll catch in testing" → Global outage.

Every production bug: "This should never happen" → Happened. "Users won't do that" → They did. "Edge case impossible" → It occurred.


Key Insights

Don't assume things work—verify. Build redundancy and fallbacks. Plan for the worst case. Murphy's Law isn't pessimism, it's realism. Better to be paranoid than surprised.