The 30-second version
Murphy's Law, in its most common phrasing, says "Anything that can go wrong will go wrong." Unlike most "laws" in this collection, it traces to one specific, datable event rather than a research paper: a 1949 U.S. Air Force program at Edwards Air Force Base, where engineer Capt. Edward A. Murphy Jr. brought sensors meant to measure G-forces during rocket-sled deceleration tests run under Lt. Col. John Paul Stapp. Every sensor came back with a useless zero reading — investigators found the gauges had been wired backward. Murphy, by most detailed accounts, said something close to: "If there's more than one way to do a job, and one of those ways will result in disaster, then somebody will do it that way." Stapp repeated a shorter version to reporters and named it after him, and engineering culture carried it from there. The useful reading isn't cosmic pessimism — it's a design instruction: once a system has more than one way of doing something, and at least one of those ways leads to failure, assume that at sufficient scale or repetition, the failure path will eventually get taken, and engineer around it before it happens rather than after.
Mental Model Compass
Where Murphy's Law sits next to three other models already in this collection about anticipating failure or misjudging effort. Click a dot to see why it sits where it does.
Click or focus a dot to read why it sits where it does.
Build the idea, one step at a time
Despite feeling like ancient folk wisdom, the named law traces to a specific, datable event. In 1949, at Edwards Air Force Base, the Air Force ran Project MX981, using a rocket sled nicknamed "Gee Whiz" to study how much deceleration the human body could survive, under the command of Lt. Col. John Paul Stapp. Engineer Capt. Edward A. Murphy Jr. arrived from Wright Field with strain-gauge sensors meant to measure G-forces on the test subject (on the run in question, a chimpanzee rather than a person). Every sensor came back reading zero. Investigators traced the problem to the gauges having been wired backward during their construction. Some retellings differ on minor details — exactly who wired them, and the precise original wording — but the useless data and the backward wiring are consistently reported. Murphy, frustrated, is reported to have said something close to: "If there's more than one way to do a job, and one of those ways will result in disaster, then somebody will do it that way." Stapp repeated a shorter version to the press and called it "Murphy's Law," and the name spread through engineering circles from there.
The useful reading of the law isn't "nothing you do matters, so don't bother" — that is the opposite of what Stapp's own team practiced. His crew used the idea to justify the reverse response: build in redundancy, double-check every connection, and plan for the failure mode before flying the test, because a crewed rocket sled gave them one shot to get it right. Treating the law as an excuse for resignation is a misreading. The engineering culture that actually formed around it treats "something will eventually go wrong" as a reason to find and close failure paths in advance, not a reason to stop trying.
The law is less a law of probability than a law of combinatorics. A process with one step and one way to do it has exactly one failure mode to worry about. A process with twenty steps, each with two or three plausible-but-wrong ways to execute it, repeated thousands of times, has an enormous number of possible failure paths — and at that scale, rare events stop being rare. This is also why the law feels truer in messy, multi-component systems (a rocket launch, a hospital, a software deployment pipeline, a supply chain) than in a single, simple, one-off decision: more interacting parts means more ways for one of them to fail, and more repetitions means those low-probability paths eventually get taken.
Taking the law seriously in practice means specific, deliberate habits: building redundancy and fail-safes into critical systems, running a Failure Mode and Effects Analysis (FMEA) to list how each component could fail before it ships, running a premortem that imagines the plan has already failed and asks why, adding margin and buffer rather than planning to the exact edge of tolerances, and — in software — the "chaos engineering" practice of deliberately injecting failures into production systems to confirm they are handled, rather than waiting to discover a failure mode the hard way during a real outage.
What it looks like in different fields
The law's home turf. Aerospace, nuclear, and medical-device engineering build in redundant systems, fail-safes, and wide safety margins specifically because a single-point failure in a complex system is a matter of when, not if, across enough operating hours. Post-mission reviews of failures like the Challenger and Columbia disasters repeatedly trace root causes back to a known, low-probability failure path that was eventually taken because it was tolerated rather than closed in advance.
Site reliability engineering treats "anything that can fail will fail, eventually, at scale" as a working assumption rather than a joke: it drives practices like chaos engineering (deliberately killing servers or injecting network failures in production to confirm the system survives), multi-region redundancy, and the working assumption that any dependency without a fallback will eventually be the thing that takes an outage down.
A single missing approval, forgotten dependency, or unclear handoff rarely sinks one task on its own, but across a large, repeated portfolio of projects, the rare failure path gets found eventually. Program managers build in buffer time, run premortems before kickoff, and use approval checklists specifically because the law describes what skipping those steps costs at scale, not just on any one project.
The familiar, personal version: the one day you leave the umbrella at home is the day it rains, and the lane you're not in is the one that moves. This is survivorship-flavored noticing more than a real law of nature in any single case, but the practical lesson still generalizes: build slack — an earlier flight connection, a spare phone charger, a backup key — into exactly the parts of a trip or day that have more than one way to go wrong.
Worked application: running a premortem before a product launch
- Assume the launch has already failed, and ask why. Gather the team before launch and don't ask "what could go wrong" — ask "it went wrong; why?" This framing, borrowed from the premortem technique, surfaces failure modes people self-censor when merely asked to speculate.
- List every step that has more than one way to execute it — a deploy script run manually, a config set differently per environment, a payment provider with more than one integration path. Those are exactly the steps Murphy's Law says will eventually be done the wrong way.
- For each one, ask what happens if it fails at the worst possible moment — peak traffic, a holiday weekend, the one engineer who understands it being on vacation — rather than an average moment, since failures don't politely wait for a slow day.
- Add redundancy, a fail-safe, or a rollback path to the highest-consequence items, not all of them equally. Treat this as portfolio risk management, not a request to gold-plate every component the same amount.
- Build margin into the schedule and into technical tolerances rather than planning to the exact edge of what's needed, since a plan with zero slack has zero room to absorb the failure you just assumed will happen.
- After launch, treat every near-miss and actual failure as data. Log it, trace it to the step that had more than one way to go, and close that specific path, rather than writing it off as bad luck.
Common mistakes
Mistaking it for fatalism
Reading the law as "nothing can be done, so don't bother planning" gets it backward. The engineering culture that coined and popularized it used it to justify more redundancy and more careful testing, not resignation.
Treating it as a literal law of probability
It isn't a formal statistical claim that failure is certain in any given instance; it's a design heuristic about complex, repeated systems. Citing it to argue a specific one-off event was somehow fated misuses it.
Confusing "can go wrong" with "equally likely to go wrong"
The law doesn't say every failure mode is equally probable or equally worth defending against. It's a reason to inventory and prioritize failure paths, not to treat all of them as equally urgent.
Mythologizing the origin story
The law is often retold as ancient sailor's or aviator's folklore. The best-documented account ties it to a specific, named 1949 Air Force test program, even though a few details — exactly who built the sensors, the precise original wording — are reported slightly differently across sources.
When not to use it
- As an argument against taking a reasonable, otherwise-sound risk when the actual cost of failure is low and reversible — treating every decision as a catastrophic failure waiting to happen is itself a planning error.
- As a stand-in for real probability and risk analysis — it's a prompt to look for failure modes, not a substitute for actually estimating how likely or costly they are.
- To assign blame after an honest, well-prepared effort still fails — the law explains why failure is possible at scale, not that any individual who experienced it should have somehow prevented the unpreventable.
- As the entire plan on its own — "we know it'll go wrong somehow" isn't a mitigation by itself; it only has value paired with the specific engineering habits (redundancy, premortems, margin) that respond to it.
Try It Yourself: build your own prompt
Answer three quick questions and get a ready-to-use prompt for applying Murphy's Law to your own situation.
Your prompt:
Save as Skill
A portable summary of Murphy's Law you can hand to an AI assistant, a teammate, or your future self, so the model gets applied the same careful way every time.
Preview