We all know Murphy, right? We’ve all heard his famous law, and most of us have invoked it at least once in our careers. But are we using it correctly?
For those who don’t know the origin story: Edward Murphy was an aerospace engineer who, in 1949, watched his technician install all the sensors in a test harness backwards on a rocket sled run. Every sensor read zero. His response wasn’t to cancel the program but to argue for designing components that physically could not be installed wrong.
The law that bears his name was a call to action. Somewhere along the way, we turned it into a reason to do nothing.
How software adopted Murphy
Software engineering adopted Murphy’s Law early. Distributed systems fail in strange ways. Networks drop packets. Disks corrupt. Processes crash mid-transaction. The law fit.
But somewhere in that adoption the meaning was lost, and “Anything that can go wrong, will” stopped being a reason to design defensively and became a reason to avoid risk entirely. Or worse, a shrug when things broke: “Murphy’s Law, what can you do?”
Now we see there are three responses to the same failure mode. Same information, different outcomes.
Three teams, same problem
Imagine this scenario: Your team needs to migrate the payment system to a new provider. Someone lists twelve ways it could fail: race conditions during the cutover, webhook format mismatches, idempotency gaps, timezone bugs in retry logic. The usual.
What happens next depends on who is in the room.
1. The “We can’t do that” team
The lead nods at the list. “Murphy’s Law,” they say, and the project dies at the planning stage. Too risky. Too many unknowns. Better to wait.
Six months later the legacy provider announces end-of-life. Now you’re doing the same migration as an emergency, with no preparation time, no staged rollout, no kill switches. The twelve failure modes are still there. You just lost the chance to address them on your terms.
The risk didn’t disappear when you postponed the decision. You traded a managed risk for an unmanaged one.
2. The “How do we do this safely?” team
Same list. Different question.
The lead asks: which of these twelve things are recoverable? Which ones need circuit breakers? What’s our rollback trigger? Which failures can we simulate in staging, and which ones only manifest in production? What’s our communication plan if transactions get stuck?
The migration happens in three phases. Each phase has a kill switch. Monitoring gets extra alerting for the specific failure modes on the list. Two of the twelve things go wrong during rollout. The system recovers in minutes because someone thought about it beforehand.
This path takes longer. It requires more meetings, more arguments about scope, more ownership decisions. It’s not the easy option. It’s just the one that works.
3. The “Just ship it” team
The lead waves off the list. Overthinking. Analysis paralysis. “We’ll handle it in production.”
The migration goes out. Three things fail simultaneously. The rollback procedure exists in a wiki page nobody has read. The on-call engineer joined two months ago and has never seen the payment system internals. It takes three days to stabilize. Customer support handles a backlog of failed transaction tickets for a week.
The excuse is the problem
These three responses share the same information. Twelve failure modes. The difference is what happens next.
The first response treats Murphy’s Law as a prediction: things will go wrong, therefore don’t try. The third treats it as irrelevant: things might go wrong, but probably won’t. The second treats it as a design constraint: things will go wrong, so build for that.
Only the second one is engineering. (Sometimes the answer after that analysis is still “don’t do it.” That’s fine. The point is you did the work.)
The first and third responses are both ways of refusing to think. One refuses to think about how to succeed. The other refuses to think about how to fail. Both end up in the same place: unprepared when reality arrives.
What you say in the room matters
Engineering leads shape how teams respond to risk. When someone raises a failure scenario in a planning meeting, you have two options:
“Good point. Let’s not do this.”
“Good point. How do we handle that?”
The second response takes thirty seconds longer. It also teaches your team that identifying risk is the start of design, not the end of discussion. Over time, you get engineers who surface problems early because they know problems lead to solutions, not cancellations.
The first response teaches the opposite. Engineers learn to keep concerns to themselves, or raise them late enough that they become someone else’s problem. You lose the early warning system that keeps projects from going off the rails.
Ownership follows interpretation
Teams that use Murphy’s Law correctly tend to own their failures. “We anticipated this could happen. Our mitigation didn’t work as expected. Here’s what we’re changing.” This builds trust. It shows the failure was considered, the response was planned, and the learning is real.
Teams that use it as an excuse tend to deflect. “Well, something was bound to go wrong eventually.” This erodes trust. It suggests the failure was inevitable, the team was helpless, and nothing will change.
Same law. Different relationship with accountability.
The law is a design requirement
Murphy’s original insight came from watching a sensor get wired backwards. His response was to make the connector asymmetric. The failure mode still existed in theory. It just became impossible in practice.
That’s the correct application. You don’t pretend failures won’t happen. You don’t refuse to act because they might. You look at each failure mode and ask what’s possible: prevention, early detection, automatic recovery, blast radius limits, or at minimum, obvious symptoms when it breaks.
Some failure modes you mitigate. Some you accept with eyes open. The point is that you made a decision, not a prediction.
Murphy’s Law shouldn’t be treated as a weather forecast. It’s a spec.
