Engineering Laws

“For a successful technology, reality must take precedence over public relations, for nature cannot be fooled.”

— Richard Feynman, Appendix F, Report of the Presidential Commission on the Space Shuttle Challenger Accident, 1986

Every trade keeps commandments. Ours are mostly scar tissue with punchlines — the collected paranoia of people who have shipped, built, or launched something and lived to be sarcastic about it. This page keeps them in two drawers: the general truths that survive any discipline, and the scar tissue particular to each trade. Software gets the deep shelves because it is the author’s trade; the others are here because they are funnier. The named laws are indexed at the back, next to the canon that keeps them.¹

General Rules

Fault and Blame

• It’s always your fault until it’s provably not your fault.
• The problem belongs to whoever discovered it until it belongs to someone else.
• Don’t prove it’s someone else’s problem. Prove it’s not yours.
• Users don’t care whose team owns the bug.
• Never attribute to malice that which is adequately explained by incompetence. — Hanlon’s Razor

Estimation and Process

• It always takes longer than you expect, even when you take into account Hofstadter’s Law.
• The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time. — the ninety-ninety rule
• When a measure becomes a target, it ceases to be a good measure. — Goodhart’s Law
• A man with a watch knows what time it is. A man with two watches is never sure. — Segal’s Law
• Adding people to a late project makes it later. — Brooks’s Law
• Work expands so as to fill the time available for its completion. — Parkinson’s Law
• Nothing is temporary. Especially temporary fixes.

Systems

• If it can fail, it will fail. — Murphy’s Law
• A complex system that works is invariably found to have evolved from a simple system that works. — Gall’s Law
• Ninety percent of everything is crap. — Sturgeon’s Law
• Every process exists because something terrible happened once.
• The unit you didn’t convert is the one that loses the spacecraft.²
• The most dangerous words in engineering are: “Nobody would ever do that.”

Safety

• Every safety rule is written in blood.
• For every major injury, 29 minor ones and 300 near-misses. — Heinrich’s Law³
• No single barrier stops an accident; you stack imperfect barriers and hope the holes don’t line up. — the Swiss cheese model⁴
• Every anomaly you survive becomes tomorrow’s procedure. — normalization of deviance⁵

Conduct

• However menial and trivial your early assignments may appear, give them your best efforts.⁶
• There is always a premium upon the ability to get things done.
• Confirm your instructions and the other fellow’s commitments in writing.
• Avoid the very appearance of vacillation.
• Don’t be timid — speak up — express yourself and promote your ideas. The quiet, mousey individual who says nothing is usually credited with having nothing to say.
• Be extremely careful of the accuracy of your statements. A wrong answer is worse than no answer; if you do not know, say so, and say you’ll find out right away.
• Be as particular as you can in the selection of your boss — in its effect upon your career, second in importance only to the selection of proper parents.

Discipline-Specific Rules

Debugging

• No matter how well it works, assume it’s broken somewhere.
• If you didn’t test it, it doesn’t work.
• If you only tested it once, it doesn’t work.
• If it works on your machine, that’s where it belongs.⁷
• The bug is never where you first think it is.
• The harder you insist “that can’t be the problem,” the more likely it’s the problem.
• Trust, but verify. Then verify the verification.⁸
• Assume the logs are lying. Then check them anyway.
• Read the error message. Actually read it.
• Before building a solution, make sure you understand the problem.
• The issue you’ve spent six hours chasing is probably a typo.
• The issue that looks like a typo probably isn’t.
• The cleverer the code, the less likely Future You will understand it.⁹

Operations

• Everything fails eventually. Design accordingly.¹⁰
• Every system is a distributed system once enough time passes.
• Every distributed system is eventually a messaging system.
• Every success story is built on a pile of postmortems.
• Production is the world’s most expensive test environment.
• There are two kinds of systems: those that are down, and those that haven’t gone down yet.
• The customer experiences one system, not seventeen microservices.

Design

• Make it work. Make it right. Make it fast. In that order.¹¹
• Every abstraction leaks eventually.¹²
• All models are wrong; some are useful.¹³
• Simple things should be simple. Complex things should be possible.¹⁴
• We should forget about small efficiencies, say about 97% of the time. Premature optimization is the root of all evil.¹⁵
• Every application has an inherent amount of complexity that cannot be removed or hidden, only moved.¹⁶ — Tesler’s Law
• There are only two hard things in Computer Science: cache invalidation and naming things.¹⁷
• The best documentation is the code. The second-best documentation is documentation.

The Software Laws

• Conway’s Law (1968): organizations design systems that mirror their communication structures.
• Wirth’s Law (1995): software gets slower faster than hardware gets faster.
• Zawinski’s Law (1990s): every program attempts to expand until it can read mail.
• Greenspun’s Tenth Rule (1993): any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
• Linus’s Law (1999): given enough eyeballs, all bugs are shallow.
• Atwood’s Law (2007): any application that can be written in JavaScript, will eventually be written in JavaScript.

The Bestiary

• Heisenbug — vanishes the moment you observe it.¹⁸
• Bohrbug — solid, repeatable, sits exactly where you expect it.
• Mandelbug — causes so tangled that bug and design become indistinguishable.
• Schrödinbug — worked fine until someone read the code and noticed.

Electrical

• The equipment works because the smoke stays inside. Let the smoke out, and it stops working.
• Ground is not ground. There is no ground — only current return paths with opinions.
• It’s not RF — until it is. Everything is a transmission line above the frequency where it starts to matter.
• Check power first. It is always the power supply until proven otherwise.

Mechanical

• If it moves and it shouldn’t: duct tape. If it doesn’t move and it should: WD-40.
• Everything is a spring. Also a mass, a damper, and a vibration source you didn’t model.
• Fatigue cracks start at the stress concentration you didn’t draw.
• Tolerances stack. The stack is always against you.
• A bearing runs fine right up until the moment it doesn’t.

Structural

• Concrete will crack. Your only choice is where.
• You don’t design structures not to fail. You design how they fail.¹⁹
• Strength, stiffness, stability — failure is whichever you forgot.
• The load finds the path you didn’t design.
• Every structure has a natural frequency. The operating speed — or the wind — will find it.²⁰
• “It’s been standing for a hundred years” is the most expensive sentence in renovation.

Civil

• As-built drawings are a work of fiction.
• Water always wins. There are two kinds of basements: those that leak and those that will.
• The most important material on site is the one you can’t see, sample, or fully characterize.
• When in doubt, make it stout.

Process

• What you don’t have, can’t leak. — inherent safety²¹
• If you think safety is expensive, try an accident.²²
• Every valve is a leak path; every pump is a seal failure in waiting.

Aerospace

• Test as you fly, fly as you test.²³
• The accident you planned for is not the accident you get.
• Murphy was one of ours — an electrical engineer on a rocket-sled program. See Systems, above.

Commandments

• If it isn’t monitored, it isn’t running.
• If it isn’t documented, it doesn’t exist.
• If it works perfectly, you’re missing something.
• The customer will always find the one workflow you never tested.²⁴
• Future You is a different person and deserves kindness.²⁵
• The root cause is usually human, even when the symptom is technical.
• Production gets a vote.

References

The Named Laws

Chronological, because the lineage is half the joke. Each entry links to the law as it lives in the lists above — and every named law in the lists links back here.

Canon

• Wikipedia: List of eponymous laws — the umbrella index.
• NASA Lessons Learned Information System — where test-as-you-fly lives, written the hard way.
• Feynman’s Appendix F — the epigraph’s primary source (Rogers Commission, 1986).
• The Jargon File — the hacker-folklore canon, in print since The Hacker’s Dictionary (1983, ed. Steele).
• laws-of-software.com — attributed, one page per law.
• murphys-laws.com — the Murphy archive, origin story included.
• “How Do Committees Invent?” — Conway’s original paper (Datamation, April 1968). Primary source.
• Trevor Kletz, What Went Wrong? Case Histories of Process Plant Disasters — process-safety case law.
• Diane Vaughan, The Challenger Launch Decision (1996) — normalization of deviance, from the source.
• James Reason, Human Error (1990) — the Swiss cheese model.
• Henry Petroski, To Engineer Is Human — the case-law canon of engineering failure.
• W. J. King, The Unwritten Laws of Engineering
  1944. — three articles from Mechanical Engineering compiled into the ur-text of this entire genre; still in print in revised editions. The original is open on Archive.org.