Murphy's Laws and Other Observations

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. Nature always sides with the hidden flaw.
8. Mother nature is a bitch.

• Murphy was an optimist.

1. You can't win.
2. You can't break even.
3. You can't even quit the game.

• Just when you see the light at the end of the tunnel, the roof caves in.

• Nothing is impossible for the man who doesn't have to do it himself.

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.

• 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.

• When a compiler accepts a program without error on the first run, the program will not yield the desired output.

• In nature, nothing is ever right. Therefore, if everything is going right ... something is wrong.

• If at first you don't succeed, transform your data set!

• Computing power increases as the square of the cost.

1. Fuzzy project objectives are used to avoid embarrassment 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.

• Variables won't; constants aren't.

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.

• There's always one more bug.

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 bad data past it.
6. If a test installation functions perfectly, all subsequent systems will malfunction.

• If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization.

• The probability of anything happening is in inverse ratio to its desirability.

• The amount of expertise varies in inverse ratio to the number of statements understood by the general public.

• Once you open a can of worms, the only way to recan them is to use a larger can (old worms never die, they just worm their way into larger cans).

• Under the most rigorously controlled conditions of pressure, temperature, volume, humidity and other variables, the computer will do as it damn well pleases.

• It works better if you plug it in.

• It won't work.

• Experience varies directly with equipment ruined.

• Nothing ever gets build on schedule or within budget.

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

• When it rains, it pours.

1. Anything that begins well ends badly.
2. Anything that begins badly ends worse.

• To estimate the time it takes to do a task: estimate the time you think it should take, multiply by two and change the unit of measure to the next highest unit. Thus, we allocate two days for a one hour t

• If it looks easy, it's tough. If it looks tough, it's damn near impossible.

• No books are lost by lending except those you particularly wanted to keep.

• If you miss one issue of any magazine, it will be the issue that contains the article, story or installment you were most anxious to read.

• All of your friends either missed it, lost it or threw it out.

• You never find the article until you replace it.

• Adding manpower to a late software makes it later.

• Once a job is fooled up, anything done to improve it will only make it worse.

• Whatever you did, that's what you planned.

• Any inanimate object, regardless of its position, configuration or purpose, may be expected to perform at any time in a totally unexpected manner for reasons that are either entirely obscure or else completely mysterious.

Some Laws in German

Gesetze der Computer-Programmierung

1. Jedes fertige Programm, das läuft, ist veraltet.
2. Jedes Programm kostet mehr und dauert länger, wenn es nochmals abläuft.
3. Wenn ein Programm nützlich ist, muß es geändert werden.
4. Wenn ein Programm nutzlos ist, muß es dokumentiert werden.
5. Ein Programm wird solange expandieren, bis es den verfügbaren Speicher füllt.
6. Der Wert eines Programmes steht im umgekehrten Verhältnis zu dem Gewicht seiner Ausgabe.
7. Die Komplexität eines Programms wächst so lange, bis sie die Fähigkeit des Programmierers übertrifft, der es weiterführen muß.

Golombs Merksätze zur Verwendung mathematischer Modelle

1. Machen Sie sich keine Sorgen wegen der Erscheinungen im 33. Stadium einer ersten Modellrechnung. (Merksatz: Cum grano salis.)
2. Extrapolieren Sie nicht über den Bereich hinaus, für den das Modell gerade noch paßt. (Merksatz: Spring nicht ins Nichtschwimmerbecken.)
3. Wenden Sie keine Modellrechnung an, solange Sie nicht die Vereinfachungen, auf denen sie beruht, geprüft und ihre Anwendbarkeit festgestellt haben. (Merksatz: Unbedingt Gebrauchsanleitung beachten.)
4. Verwechseln Sie nie das Modell mit der Realität. (Merksatz: Versuch nicht, die Speisekarte zu essen.)
5. Verzerren Sie nicht die Realität, damit sie zu Ihrem Modell paßt. (Merksatz: Wende nie die Prokrustesmethode an.)
6. Beschränken Sie sich nicht auf ein einziges Modell. Um verschiedene Aspekte eines Phänomens zu beleuchten, ist es oft nützlich, verschiedene Modelle zu haben. (Merksatz: Polygamie muß legalisiert werden.)
7. Halten Sie niemals an einem überholten Modell fest. (Merksatz: Es hat keinen Sinn, toten Pferden die Peitsche zu geben.)
8. Verlieben Sie sich nicht in Ihre Modelle. (Merksatz: Pygmalion.)
9. Wenden Sie nicht die Begriffe des Gegenstands A auf den Gegenstand B an, wenn es beiden nichts nutzt. (Merksatz: Neuer Wein in alten Schläuchen.)
10. Unterliegen Sie nicht dem Irrglauben, Sie hätten den Dämon vernichtet, wenn Sie einen Begriff dafür haben. (Merksatz: Rumpelstilzchen.)