MURPHY AND COMPANY



Murphy's Laws:
  1. If anything can go wrong, it will.
  2. If there is a possibility of several things going wrong, the one that will cause the most damage will be the first one to go wrong.
  3. If anything just cannot go wrong, it will anyway.
  4. If you perceive that there are four possible ways in which something can go wrong, and circumvent these, then a fifth way, unprepared for will promptly develop.
  5. Left to themselves, things tend to go from bad to worse.
  6. If everything seems to be going well, you have obviously overlooked something.
  7. Everything takes longer than you think.
  8. Whenever you set out to do something, something else must be done first.
  9. Nature always sides with the hidden flaw.
  10. Mother Nature is a bitch.
Murphy's Original Law:
If there are two or more ways to do something, and one of those ways can result in a catastrophe, then someone will do it.

Murphy's Constant:
Matter will be damaged in direct proportion to its value.

Murphy's Paradox:
Doing it the hard way is always easier.

Forsyth's Second Corollary to Murphy's Laws:
Just when you see the light at the end of the tunnel, the roof caves in.

Zymurg's Seventh Exception to Murphy's Laws:
When it rains, it pours.

Quantization Revision of Murphy's Law:
Everything goes wrong all at once.

O'Toole's Commentary on Murphy's Laws:
Murphy was an optomist.



Other Laws & Observations:

Arnold's Laws of Documentation:
  1. If it should exist, it doesn't.
  2. If it does exist, its out of date.
  3. Only documentation for useless programs transcends the first two.
Beckith's Law of Expansion:
Programs ssek to expand themselves beyond available memory.

Belov's Law:
The relative importance of a computer system is inversely proportional to the contrivedness of its acronym.

Blum's Theorem:
I have a good idea why it's hard to verify programs. They're usually wrong.

Bove's Theorem:
The remaining work to finish in order to reach your goal increases as the deadline approaches.
The Briggs/Chase Law of Program Development:
To determine how long it will take to write and debug a program, take your best estimate, multiply that by two, add one, and convert to the next higher units. Thus, we allocate two days for a one hour task
Brook's Laws:
  1. Adding manpower to a late software project makes it later.
  2. Whenever a system becomes completely defined, some damn fool discovers something which either abolishes the system or expands it beyond recognition.
  3. If at first you don't succeed, transform your data set!
Cahn's Axiom:
When all else fails, read the manuals.

Cheop's Law:
Nothing ever gets build on schedule or within the budget.

Crane's Law:
There is no such thing as a free lunch.

Complexity Law #1:
It is easier to change the specification to fit the program than vice versa.

Complexity Law #2:
It is easier to write an incorrect program that understand a correct one.

Finangle's Fourth Law:
Once a job is fouled up, anything done to improve it will only make it worse.

Flon's Law:
There is not now, and never will be, a language in which it is the least bit difficult to write bad programs.
Fyfe's Laws of Revision:
  1. Information necessitating a change of design will be conveyed to the designer after and only after the design is complete.
  2. The more innocuous the modification appears to be, the further its influence will extend and the more the design will have to be redrawn.
  3. If, when completion of a design is imminent, field dimensions are finally supplied as they actually are, instead of as they were meant to be, it is always simpler to start over from scratch.
Gilb's Laws of Unreliability:
  1. Computers are unreliable, but humans are even more unreliable.
  2. Any system that depends upon human reliability is unreliable.
  3. Undetectable errors are infinite in variety, in contrast to detectable errors, which by definition are limited.
  4. Investment in reliability will increase until it exceeds the probable cost of errors, or until someone insists on getting some useful work done.
Golub's Laws of Computerdom:
  1. Fuzzy project objectives are used to avoid embarassment of estimating the corresponding costs.
  2. A carelessly planned project takes three times longer to complete than expected; A carefully planned project takes only twice as long.
  3. The effort required to correct course increases geometrically with time.
  4. Project teams detest weekly progress reporting because it so vividly manifests their lack of progress.
Gray's Law of Programming:
n+1 trivial tasks are expected to be accomplished in the same time as n trivial tasks.

Grosch's Computer Economics Law:
Computing power increases as the square of the cost increases.

Harvard's Law, as applied to computers:
Under the most rigorously controlled conditions of pressure, temperature, volume, humidity and other variables, the computer will do as it damn well pleases.

IBM's Pollyanna Principle:
Machines should work. People should think.

Ichikawa's Law:
If a machine can be made so that an idiot can use it, then only an idiot will use it.

Karl's Programming Proverb:
When in doubt, print 'em out.
The Laws of Computer Programming:
  1. Any given program, when running, is obsolete.
  2. Any given program costs more and takes longer each time it is run.
  3. If a program is useful, it will have to be changed.
  4. If a program is useless, it will have to be documented.
  5. Any given program will expand to fill all the available memory.
  6. The value of a program is inversely proportional to the weight of its output.
  7. Program complexity grows until it exceeds the capability of the programmer who must maintain it.
The Laws of Program Demonstration:
  1. If a listener nods his head when you're explaining your program, wake him up.
  2. The number of faults encountered during a presentation, is proportional to the number of viewers.
  3. The amount of errors that will be encountered during actual program usage is proportional to the number of statements understood during the presentation.
  4. Somebody among the audience is always more smart than you are.
  5. Whatever happens, look as if you intended it to happen.
  6. If you cannot convince them, confuse them.
The Law of Weekend Project:
Even the smallest of projects will expand to fill the entire weekend.

Lerman's Law of Technology:
Any technical problem can be overcome given enough time and money.

Corollary to Lerman's Law:
You are never given enough time or money.

Levy's Ninth Law:
Only God can make a random selection.

Lubarsky's Law of Cybernetic Entomology:
There's always one more bug.

Lyall's Conjecture:
If a computer cable has one end, then it has another.

Feynman Problem-Solving Algorithm:
(1) Write down the problem; (2) Think Hard; (3) Write down the answer.

Hoare's Law of Large Problems:
Inside every large problem, there is a small problem struggling to get out.

Manley's Maxim:
Logic is a systematic method of coming to the wrong conclusion with confidence.

Mencken's Law :
For every complex problem, there is a solution that is simple, neat and wrong.

Mickels Software Requirement:
Reliable software must kill people reliably.

Micro Credo:
Never trust a computer bigger than you can lift.

Miller's Axiom:
Internetworks, by nature are exceedingly complex. When they work, they are the marvels of engineering. When they fail, you are in BIG trouble.

Mosely's Law:
Accidents happen when two people try to be clever at the same time.

Mosher's Law of Software Engineering:
Don't worry if it doesn't work right. If everything did, you'd be out of a job.

The 90/90 Rule of Project Schedules:
The first 90 percent of the task takes 10 percent of the time. The last 10 percent of the task takes 90 percent of the time.

Osborn's Law:
Variables won't; constants aren't.

Peer's Law:
The solution to a problem changes the problem.

Pierce's Law:
In any computer system, the machine will always misinterpret, misconstrue, misprint, or not evaluate any math or subroutines or fail to print any output on at least the first run through.

Corollary to Pierce's Law:
When a compiler accepts a program without error on the first run, the program will not yield the desired output.

The Program Bug Continuum:
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to one instruction which doesn't work.

Putt's Law:
Technology is dominated by two types of people: those who understand what they don't manage, and those that manage what they don't understand.

Robert's Axiom:
Only errors exist.

Rule of Accuracy:
When working toward the solution of a problem, it always helps if you know the answer.

Rule of Failure:
If at first you don't succeed, destroy all evidence that you have tried.

Rule of Reason:
If nobody uses it, there's a reason.

Sattinger's Law:
It works better if you plug it in.

Schyer's Law of Relativity:
If the code and the comments disagree, then both are probably wrong.

Shaw's Principle:
Build a system that even a fool can use, and only a fool will want to use it.

Snyder's Law:
The usefulness of a computer printout is inversely proportional to its weight.
Spencer's Laws of Data:
  1. Anyone can make a decision given enough facts.
  2. A good manager can make a decision without enough facts.
  3. A perfect manager can operate in perfect ignorance.
Steele's Compiler Benchmark:
If the programmer can simulate a construct faster than the compiler can implement the construct itself, then the compiler writer has blown it badly.

Steinbach's Guideline for Systems Programming:
Never test for an error condition you don't know how to handle.

Stockmayer's Theorem:
If it looks easy, it's tough. If it looks tough, it's damn near impossible.

The Tao of Programming:
Though a program be but three lines long, someday it will have to be maintained.

Taylor's Laws of Programming:
Never write it in C if you can do it in 'awk';
Never do it in 'awk' if 'sed' can handle it;
Never use 'sed' when 'tr' can do the job;
Never invoke 'tr' when 'cat' is sufficient;
Avoid using 'cat' whenver possible.
Troutman's Postulates:
  1. Profanity is the one language understood by all programmers.
  2. Not until a program has been in production for six months will the most harmful error be discovered.
  3. Job control cards that positively cannot be arranged in improper order will be.
  4. Interchangeable tapes won't.
  5. If the input editor has been designed to reject all bad input, an ingenious idiot will discover a method to get bed data past it.
  6. If a test installation functions perfectly, all subsequent systems will malfunction.
Thompson's Observation:
The steady state of disks is full.

Turnaucka's Law:
The attention span of a computer is only as long as its electrical cord.
The Unnamed Mimeo Sheet Laws:
  1. It will not work the first time.
  2. It probably will not work on the second attempt.
  3. Immediately after you walk away from the printer, the paper will jam.
  4. If you fail to back up your disk, it will ruined by the drive.
  5. All software contains a bug, which you will discover at the least opportune moment.
Zimmerman's Law of Complaints:
Nobody notices when things go right.

Zymurgy's First Law of Evolving System Dynamics:
Once you open a can of worms, the only way to recan them is to use a larger can.



[Back to Home Page]