Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Murphy's Laws for programming ?

60 views
Skip to first unread message

Blair P. Houghton

unread,
Sep 22, 1991, 11:11:11 PM9/22/91
to
In article <1991Sep22....@idaho.uucp> rhod...@idaho.uucp (III) writes:
>Does any happen to have a list a Murphy-law like sayings
>for computer programming (I'm sure you've seen the posters)?

Not a list, but try this: "data expands to fill the available space."

--Blair
"Walking Bicyclopedia."

III

unread,
Sep 22, 1991, 7:53:07 PM9/22/91
to
Does any happen to have a list a Murphy-law like sayings
for computer programming (I'm sure you've seen the posters)?

I'm looking for sayings/anecdotes/rules-of-thumb along the line of
Oualline's Law of Documentation. You know, the sort of empirical laws
that have been developed after years of programming and
dealing with users. I'm sure there are some very good ones out there.
Perhaps there is an already compiled list somewhere?

tnx,
--
-----------
Joel Rhodes * rhod...@othello.studsvik.com
Studsvik of America,INC. * uunet!idaho!othello!rhodesii
Nuclear Code Development * Idaho Falls,ID. USA ph 208-522-8443

D John McKenna

unread,
Sep 23, 1991, 2:36:33 AM9/23/91
to
"if it errors, delete it"
You'd be suprised how many bugs this has fixed

John West

Roger MacNicol

unread,
Sep 23, 1991, 9:23:16 AM9/23/91
to
>In article <1991Sep22....@idaho.uucp> rhod...@idaho.uucp (III) writes:
>>Does any happen to have a list a Murphy-law like sayings
>>for computer programming (I'm sure you've seen the posters)?

The best example of the poster that I have seen is the one available by post
from the Boston Computer Museum, including:
"Variables won't, Constants aren't"

As for verification of Murphy's Laws in general. There was a blow-out on a
North Sea Oil Rig in the 70's because a blow-out preventer had been
installed upside down. The name of the chief engineer who installed it?
A certain Mr Murphy, of course. "If anything can be installed upside
down, it will"
--
Roger MacNicol, Software Engineer
Vmark Software, Inc., 5 Strathmore Road, Natick, MA 01760, USA
Internet: uvmark!ro...@merk.com, UUCP: uunet!merk.com!uvmark!roger
Phone: (508) 655-3700, Fax: (508) 655-8395

Ronald van Loon

unread,
Sep 23, 1991, 11:30:11 AM9/23/91
to
In <1991Sep22....@idaho.uucp> rhod...@idaho.uucp (III) writes:

| "Does any happen to have a list a Murphy-law like sayings
| "for computer programming (I'm sure you've seen the posters)?

Well, I got this from the Henry III jokelist this morning; they're not all
computer related, but have fun with them anyway.

Good ol' Murphy

----------------------------------------------------

ACTION'S LAW
Power tends to corrupt; absolute power corrupts absolutely.

ALBRECHT'S LAW
Social innovations tend to the level of minimum tolerable well-being.

ALLEN'S (or CANN'S) AXIOM
When all else fails, read the instructions.

BOREN'S FIRST LAW
When in doubt, mumble.

BO DIDDELEY'S OBSERVATION ON THE LAW:
Always take a lawyer with you, and bring another lawyer to watch him.

BOVE'S THEOREM
The remaining work to finish in order to reach your goal
increases as the deadline approaches.

BOWIE'S THEOREM
If an experiment works, you must be using the wrong equipment.

BRILLIANT'S OBSERVATION ON MODERN ART:
Not all our artists are playing a joke on the public.
Some are genuinely mad.

BRILLIANT'S LAW OF LIMITED AMBITION:
If you can't learn how to do it well
learn how to enjoy doing it poorly.

BROOK'S LAW
Adding manpower to a late software project makes it later.

CANADA BILL JONES' MOTTO
It's morally wrong to allow naive end users to keep their money.

CANN'S (or ALLEN'S) AXIOM
When all else fails, read the instructions.

CARLSON'S CONSOLATION
Nothing is ever a complete failure; it can always serve as a bad
example.

CLARKE'S THIRD LAW
Any sufficiently advanced technology is indistinguishable from magic.

COHN'S LAW
The more time you spend in reporting on what you are doing, the less
time you have to do anything. Stability is achieved when you spend
all your time reporting on the nothing you are doing.

CONWAY'S LAW
In any organization there will always be one person who knows what is
going on. This person must be fired.

LAW OF CONTINUITY
Experiments should be reproducible. They should all fail in the same
way.

CORRESPONDENCE COROLLARY
An experiment may be considered a success if no more than half of your
data must be discarded to obtain correspondence with your theory.

CROPP'S LAW
The amount of work done varies inversely with the amount of time spent
in the office.

CUTLER WEBSTER'S LAW
There are two sides to every argument, unless a person is personally
involved, in which case there is only one.

DEADLINE-DAN'S DEMO DEMONSTRATION
The higher the "higher-ups" are who've come to see your demo, the
lower your chances are of giving a successful one.

DEMIAN'S OBSERVATION
There is always one item on the screen menu that is mislabeled and
should read "ABANDON HOPE ALL YE WHO ENTER HERE".

DENNISTON'S LAW
Virtue is its own punishment.

DOW'S LAW
In a hierarchical organization, the higher the level, the greater the
confusion.

DR. CALIGARI'S COME-BACK
A bad sector disk error occurs only after you've done several hours of
work without performing a backup.

ESTRIDGE'S LAW
No matter how large and standardized the marketplace is, IBM can
redefine it.

FINAGLE'S LAWS
1) Once a job is fouled up, anything done to improve it makes it worse.
2) No matter what results are expected, someone is always willing to fake
it.
3) No matter what the result, someone is always eager to misinterpret it.
4) No matter what occurs, someone believes it happened according to his
pet theory.

FINAGLE'S RULES:
1) To study an application best, understand it thoroughly before you
start.
2) Always keep a record of data. It indicates you've been working.
3) Always draw your curves, then plot the reading.
4) In case of doubt, make it sound convincing.
5) Program results should always be reproducible. They should all
fail in the same way.
6) Do not believe in miracles. Rely on them.

FINAGLE'S LAW OF GOVERNMENT CONTRACTING:
Dealing with the government is like kicking a 300-pound sponge.

FINAGLE'S LAW OF MILITARY SUPERIORITY:
The bigger they are
The harder they hit.

FINSTER'S LAW
A closed mouth gathers no feet.

FIRST RULE OF HISTORY
History doesn't repeat itself -- historians merely repeat each other.

FLO CAPP'S OBSERVATION:
The next best thing to doing something smart is not doing something stupid.

FRANKLIN'S RULE
Blessed is the end user who expects nothing, for he/she will not be
disappointed.

GILB'S LAWS OF UNRELIABILITY
1) At the source of every error which is blamed on the computer you will
find at least two human errors, including the error of blaming it on
the computer.
2) Any system which depends on human reliability is unreliable.
3) Udetectable 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.

GINSBERG'S THEOREM
1) You can't win.
2) You can't break even.
3) You can't even quit the game.

GLYME'S FORMULA FOR SUCCESS
The secret of success is sincerity. Once you can fake that, you've
got it made.

GOEBEL'S LAW OF USELESS DIFFICULTY:
Just because it's hard
Doesn't mean it's worth the effort.

GOEBEL'S SECOND LAW OF USELESS DIFFICULTY:
The fastest way to get something done
is to determine that it isn't worth doing.

GOEBEL'S LAW OF COMPUTER SUPPORT:
Troubleshooting a computer over the telephone is like having sex
through a hole in a board fence. It can be done but it is neither
EASY nor PLEASANT.

GOEBEL'S LAW OF SOFTWARE COMPATIBILITY:
A statement of absolute functional equivalence made in bold print
followed by several pages of qualifications in fine.

GOEBEL'S THEOREM OF SOFTWARE SCHEDULES:
Always multiply a software schedule by pi. This is because you
think you're going in a straight line but always end up going full
circle.

GOEBEL'S LAW OF PRODUCT INTRODUCTIONS:
A future product release date does NOT say when a product will be
introduced. All it says it that you don't have a chance in HELL of
seeing it before that time.

GOEBEL'S OBSERVATION ON UTOPIA:
If everyone believed in Peace
They would immediately begin fighting over the best way to achieve it.

GOEBEL'S LAW OF INTELLECTUAL OBSCURITY:
WHAT FUN IS IT TO BE AN EXPERT IF YOU MAKE YOURSELF EASY TO UNDERSTAND?

THE GOLDEN RULE OF ARTS AND SCIENCES
Whoever has the gold makes the rules.

GOLD'S LAW
If the shoe fits, it's ugly.

GORDON'S FIRST LAW
If a research project is not worth doing at all, it is not worth doing
well.

GOVERNMENT'S LAW
There is an exception to all laws.

GREEN'S LAW OF DEBATE
Anything is possible if you don't know what you're talking about.

GUMMIDGES'S LAW
The amount of expertise varies in inverse proportion to the number
of statements understood by the general public.

GUMPERSON'S LAW
The probability of a given event occurring is inversely proportional
to its desirability.

HANLON'S RAZOR
Never attribute to malice that which is adequately explained by
stupidity.

HARP'S COROLLARY TO ESTRIDGE'S LAW
Your "IBM PC-compatible" computer grows more incompatible with every
passing moment.

HARRISON'S POSTULATE
For every action, there is an equal and opposite criticism.

HELLER'S LAW
The first myth of management is that it exists.

HINDS' LAW OF COMPUTER PROGRAMMING
1) Any given program, when running, is obsolete.
2) If a program is useful, it will have to be changed.
3) If a program is useless, it will have to be documented.
4) Any given program will expand to fill all available memory.
5) The value of a program is proportional to the weight of its output.
6) Program complexity grows until it exceeds the capability of the
programmer who must maintain it.
7) Make it possible for programmers to write programs in English, and
you will find that programmers cannot write in English.

HOARE'S LAW OF LARGE PROGRAMS
Inside every large program is a small program struggling to get out.

HUBBARD'S LAW
Don't take life too seriously; you won't get out of it alive.

JENKINSON'S LAW
It won't work.

JOHNSON-LAIRD'S LAW
Toothache tends to start on Saturday night.

LARKINSON'S LAW
All laws are basically false.

THE LAST ONE'S LAW OF PROGRAM GENERATORS
A program generator creates programs that are more "buggy" than
the program generator.

LIEBERMAN'S LAW
Everybody lies; but it doesn't matter, since nobody listens.

LYNCH'S LAW
When the going gets tough, everyone leaves.

MASON'S FIRST LAW OF SYNERGISM
The one day you'd sell you soul for something, souls are a glut.

MAY'S LAW
The quality of correlation is inverely proportional to the density
of control. (The fewer the data points, the smoother the curves.)

MENCKEN'S LAW
There is always an easy answer to every human problem -- neat,
plausible, and wrong.

MESKIMEN'S LAW
There's never time to do it right, but always time to do it over.

MUIR'S LAW
When we try to pick out anything by itself, we find it hitched to
everything else in the universe.

MURPHY'S LAWS
1) If anything can go wrong, it will (and at the worst possible moment).
2) Nothing is as easy as it looks.
3) Everything takes longer than you think it will.

MURPHY'S FOURTH LAW
If there is a possibility of several things going wrong, the one
that will cause the most damage will be the one to go wrong.

MURPHY'S LAW OF THERMODYNAMICS
Things get worse under pressure.

NINETY-NINETY RULE OF PROJECT SCHEDULES
The first ninety percent of the task takes ninety percent of the
time, and the last ten percent takes the other ninety percent.

NIXON'S THEOREM
The man who can smile when things go wrong has thought of someone
he can blame it on.

NOLAN'S PLACEBO
An ounce of image is worth a pound of performance.

OLIVER'S LAW OF LOCATION
No matter where you are, there you are.

O'REILLY'S LAW OF THE KITCHEN
Cleanliness is next to impossible.

OSBORN'S LAW
Variables won't, constants aren't.

O'TOOLE'S COMMENTARY ON MURPHY'S LAW
Murphy was an optimist.

PARKINSON'S LAW
Work expands to fill the time available for its completion.

PARKINSON'S LAW, MODIFIED
The components you have will expand to fill the available space.

PEER'S LAW
The solution to a problem changes the problem.

PETER'S PRINCIPLE
In every hierarchy, each employee tends to rise to the level of his
incompetence.

THE LAW OF THE PERVERSITY OF NATURE
You cannot determine beforehand which side of the bread to butter.

PUDDER'S LAW
Anything that begins well will end badly. (Note: The converse of
Pudder's law is not true.)

RHODE'S COROLLARY TO HOARE'S LAW
Inside every complex and unworkable program is a useful routine
struggling to be free.

ROBERT E. LEE'S TRUCE
Judgement comes from experience; experience comes from poor judgement.

RUDIN'S LAW
In a crisis that forces a choice to be made among alternative courses
of action, people tend to choose the worst possible course.

RULE OF ACCURACY
When working toward the solution of a problem it always helps you to
know the answer.

RYAN'S LAW
Make three correct guesses consecutively and you will establish
yourself as an expert.

SATTINGER'S LAW
It works better if you plug it in.

SAUSAGE PRINCIPLE
People who love sausage and respect the law should never watch either
one being made.

SHAW'S PRINCIPLE
Build a system that even a fool can use, and only a fool will want
to use it.

SNAFU EQUATIONS
1) Given any problem containing N equations, there will be N+1 unknowns.
2) An object or bit of information most needed will be least available.
3) Any device requiring service or adjustment will be least accessible.
4) Interchangeable devices won't.
5) In any human endeavor, once you have exhausted all possibilities and
fail, there will be one solution, simple and obvious, highly visible
to everyone else.
6) Badness comes in waves.

STEWART'S LAW OF RETROACTION
It is easier to get forgiveness than permission.

THOREAU'S THEORIES OF ADAPTATION
1) After months of training and you finally understand all of a program's
commands, a revised version of the program arrives with an all-new
command structure.
2) After designing a useful routine that gets around a familiar "bug" in
the system, the system is revised, the "bug" taken away, and you're
left with a useless routine.
3) Efforts in improving a program's "user friendliness" invariable lead
to work in improving user's "computer literacy".
4) That's not a "bug", that's a feature!

THYME'S LAW
Everything goes wrong at once.

THE LAW OF THE TOO SOLID GOOF
In any collection of data, the figures that are obviously correct
beyond all need of checking contain the errors.

Corollary 1: No one you ask for help will see the error either.

Corollary 2: Any nagging intruder, who stops by with unsought advice,
will spot it immediately.

UNNAMED LAW
If it happens, it must be possible.

WEILER'S LAW
Nothing is impossible for the man who doesn't have to do the work.

WEINBERG'S COROLLARY
An expert is a person who avoids the small errors while sweeping on to
the grand fallacy.

WEINBERG'S LAW
If builders built buildings the way programmers write programs, then
the first woodpecker that came along would destroy civilization.

WHITEHEAD'S LAW
The obvious answer is always overlooked.

WILCOX'S LAW
A pat on the back is only a few centimeters from a kick in the pants.

WOOD'S AXIOM
As soon as a still-to-be-finished computer task becomes a
life-or-death situation, the power fails.

WOODWARD'S LAW
A theory is better than its explanation.

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.


LAWS OF PROJECT MANAGEMENT

1. No major project is ever installed on time, within budgets, with the
staff that started it. Yours will not be the first.
2. Projects progress quickly until they become 90 percent complete, then
they remain at 90 percent complete forever.
3. One advantage of fuzzy project objectives is that they let you avoid the
embarrassment of estimating the corresponding costs.
4. When things are going well, something will go wrong.
When things just can't get any worse, they will.
When things appear to be going better you have overlooked something.
5. If project content is allowed to change freely, the rate of change will
exceed the rate of progress.
6. No system is ever completely debugged. Attempts to debug a system
inevitably introduce new bugs that are even harder to find.
7. A carelessly planned project will take three times longer to complete
than expected; a carefully planned project will take only twice as
long.
8. Project teams detest progress reporting because it vividly manifests their
lack of progress.

----------------------------------------------------------------

--
Ronald van Loon (rvl...@cv.ruu.nl, rl...@cs.ruu.nl)

3D Computer Vision Research Group, Utrecht University,
Utrecht, The Netherlands.

Yanek Martinson

unread,
Sep 23, 1991, 4:11:42 PM9/23/91
to

MURFCOMP.TXT - Murphy's Computer Laws

---------------------------------------------------------------------------

LAWS OF COMPUTER PROGRAMMING

1. Any given program, if running, is obsolete.

2. Any given program costs more, and takes longer.

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 program will expand and fill all of available memory -- plus
one byte.

6. The value of a program is proportional to the weight of its output.

7. Program complexity grows until it exceeds the capability of the


programmer who must maintain it.

TROUTMAN'S PROGRAMMING POSTULATES

1. If the test installation functions perfectly, all subsequent
systems will malfunction.

2. The most harmful error of any program will not be discovered until
the program has been in production for at least six months.

3. A Batch Stream that can not be arranged in improper order will be.

4. Constants aren't.

5. Variables won't.

6. Interchangeable Tapes won't.

7. Profanity is the one language that all programmers know the syntax of.


GILB'S LAWS OF UNRELIABILITY

1. Computers are unreliable. Humans are worse.

2. Any system which depends on human reliability is unreliable.

3. Undetectable error are infinite in variety. Detectable errors do
not exist, unless deadline is less than three hours away.

4. Investment in reliability will increase until it exceeds the


probable cost of errors, or until someone insists on getting some

real work done.


BROOK'S LAW

Any manpower added to a late project makes it later.


LAWS OF COMPUTERDUM ACCORDING TO GOLUB

1. Fuzzy project objectives are used to avoid the embarrasment of
estimating the corresponding costs.

2. Carelessy planned projects take three times longer to complete than
expected. Carefully planned projects take only three times longer to
complete than expected.

3. Programmers detest weekly status reporting because it so vividly


manifests their lack of progress.

LUBARSKY'S LAW OF CYBERNETIC ENTOMOLOGY

There is always one more bug.


SHAW'S PRINCIPLE

Build a system that even a fool can use, and only a fool will

use it.

IBM POLLYANNA PRINCIPLE

Machines should work. People should think.


GRAY'S LAW OF PROGRAMMING

"n+1" trivial tasks are expected to be accomplished in tha same time
as "n" trivial tasks.

LOGG'S REBUTTAL TO GRAY'S LAW

"n+1" trivial tasks take twice as long as "n" trivial tasks.


WEINBERG'S SECOND LAW

If builders built building the way that programmers program programs,
the first woodpecker to come along would destroy civiliization.


-------------------------------------------------------------------------

Thanx to :

Ross M. Greenberg @ NYU ----> allegra!cmcl2!acf4!greenber <----

-------------------------------------------------------------------------

Murphys Computer Laws, Part I.

Observations:
Murphy Never Would have used computers, but would have loved them.

Bove's Theorem:
The remaining work required in order to finish a project increases
as the deadline approaches.

Brook's Law:


Adding manpower to a late software project makes it later.

Canada Bill Jones' Motto:


It's morally wrong to allow naive end users to keep their
money.

Cann's Axiom:


When all else fails, read the instructions.

Clarke's Third Law:
Any sufficiently advanced technology is indistingushable
from Magic.

Deadline Dan's Demo Demonstration:
Every task takes twice as long as you think it will take.
If you double the time you think it will take, it will
actually take four times as long.

Murphy's Computer Laws, Part II.

Demian's Observation:


There is always one item on the screen menu that is

misslabeled and should read "ABANDON HOPE ALL YE WHO ENTER
HERE."

Dr. Caligari's Comeback:
Disk errors occur only after you've done
several hours of work without making a backup.

Estridge's Law:
No matter how large and standardized the marketplace, IBM
can re-define it.

Finagle's Rules:
1) To study an appliplication best, understand it
thoroughly before you start.
2) Always keep a record of Data. It indicates you've


been working.
3) Always draw your curves, then plot the reading.
4) In case of doubt, make it sound convincing.

5) Program results should always be reproducable. They
should all fair the sa

Stephen Ollis

unread,
Sep 23, 1991, 8:21:57 PM9/23/91
to
Not quite directly related, but my brother was going to a local university, and
they had an orientation booklet that had a lot of `Murphy style' laws.. A lot
of people got stuck on the following `law'...


COLES LAW: Thinly sliced cabbage...


+-------------------+---------------------------------+-----------------------+
|Steve Ollis, | Email: ol...@redbck.stl.dec.com
| Ph: 61 2 561 5675 |
|DIGITAL, Australia | `Carpe Diem - Sieze the day' |
Fax: 61 2 561 5488 |
+-------------------+---------------------------------+-----------------------+

Greg Martin

unread,
Sep 23, 1991, 6:14:55 PM9/23/91
to

This might help, I heard it around the lab somewhere:

Programming is the art of debugging a blank sheet of paper.

Greg


--
-----------------------------------------------------------------------------
* Greg Martin gma...@cs.umr.edu The opinions expressed above are mine *
* "I sing the hypotenuse, sweeping and only mine. *
* square of the other sides" - T'Vau, How Much For Just the Planet *

Don Nichols (DoN.)

unread,
Sep 23, 1991, 6:43:06 PM9/23/91
to

"If builders built buildings the way programmers write programs, the
first woodpecker to come along would destroy civilization" (Weinberger's
law, I think)

"On a clear disk you can seek forever."


--
Donald Nichols (DoN.) | Voice (Days): (703) 664-1585 (Eves): (703) 938-4564
D&D Data | Email: <dnic...@ceilidh.beartrack.com>
I said it - no one else | <dnic...@ceilidh.aes.com>
--- Black Holes are where God is dividing by zero ---

Charlie Gibbs

unread,
Sep 24, 1991, 12:08:41 AM9/24/91
to

Some thoughts on Murphy's Laws:

"Never" is about six months. If you don't test for something
because the customer said it'll never happen, the system will
die six months later when it does. You will, of course, be
held responsible.

Users don't know what they want until you give them something else.

Charli...@mindlink.bc.ca
For every vision there is an equal and opposite revision.

Jon Konrath

unread,
Sep 24, 1991, 2:58:10 AM9/24/91
to
In article <1991Sep24.0...@ux1.cso.uiuc.edu> rka2...@uxa.cso.uiuc.edu (Rubio) writes:
>Murphy's First Corollary:
>
>If Murphy's Law can go wrong, it will.
>
>
>
>Murphy's Second Corollary:
>
>If Murphy's First Corollary can go wrong, it will.
>
>
>
>(Murphy gave up after this. :-)
>
>
>--rubio (ru...@uiuc.edu)
>
>

But what if Mr. Murphy learned scheme, and implemented it with good recursion?

-j
--
Jonathan R. Konrath, consultant, University Computing Services
Jkon...@bronze.ucs.indiana.edu (Ultrix)
Jkon...@dakota.ucs.indiana.edu (NeXTmail)
(812) 333-2254 (Voice)

USENET News System

unread,
Sep 23, 1991, 9:41:56 PM9/23/91
to
In article <65...@inews.intel.com> bhou...@hopi.intel.com (Blair P. Houghton) writes:
>In article <1991Sep22....@idaho.uucp> rhod...@idaho.uucp (III) writes:
>>Does any happen to have a list a Murphy-law like sayings
>>for computer programming (I'm sure you've seen the posters)?

I have a 'Mini Murphy's law on Computers' on my office wall.

The sayings on it are:

************

When all else fails, read the instructions.

The solution to a problem changes the problem.

It works better if you plug it in.

At the source of every mistake blamed on the computer is at least 2
human errors, including the mistake of blaming it on the computer.

The higher the 'higher-ups' are who've come to see your demo, the

lower the chances are of giving a successful one.

Thats not a bug, but a feature.

Remember, any given program, when running is obsolete.

Any given program will expand to fill all available memory.

Any system which depends on human reliability is unreliable.

The man who can smile when things go wrong has thought of someone he
can blame it on.

Judgement comes from experience. Experience comes from poor judgement.

As soon as a still to be finished computer task becomes crucial, the
power fails.

************

The address on the bottom of the poster is:
LLansa Crafts,
145 Gressons Rd,
RD 3,
Rangiora,
New Zealand.

--
Colin G. Eagle
Internet: C.E...@massey.ac.nz
Voice: +64 6 3569099 x 7523 Fax: +64 6 3505611
School of Mathematical and Information Sciences, Massey University,
Palmerston North, New Zealand.
--
--
Colin G. Eagle
Internet: C.E...@massey.ac.nz
Voice: +64 6 3569099 x 7523 Fax: +64 6 3505611
School of Mathematical and Information Sciences, Massey University,
Palmerston North, New Zealand.

D John McKenna

unread,
Sep 24, 1991, 1:46:27 AM9/24/91
to
ro...@uvmark.uucp (Roger MacNicol) writes:
> "Variables won't, Constants aren't"

Try passing a structured constant to a var parameter in Turbo Pascal.
Took me forever to work that one out. (The var parameter was 'hidden' -
it was in a procedure that I didn't write, and didn't expect to modify
its parameters)

John West

Rubio

unread,
Sep 23, 1991, 10:42:44 PM9/23/91
to

Dan Sorenson -- Seed Testing Labortory

unread,
Sep 23, 1991, 11:00:28 PM9/23/91
to
In article <1991Sep23.1...@cv.ruu.nl> rvl...@cv.ruu.nl (Ronald van Loon) writes:

[480 lines of great Murphy axioms deleted to save space]

Thank you, Ronald! I really needed a few of these to put on the wall
of my cag... er... cubicle.
I have a few more printed as posters from Perfection Form Company,
Logan, Ia., and I've never seen them before. To wit:

Uhlman's Razor: When stupidity is sufficient explanation, there is
no need to have recourse to any other. -- Michael Uhlman, Asst. Attorney Gen.

The Douglas Paper Airplane Principle: When the weight of the paperwork
equals the weight of the plane, the plane will fly. -- Michael Douglas

The Rule of 2 1/2: Any military project will take twice as long as
planned, cost twice as much, and produce only half of what is wanted.
-- Cyrus Vance, Former Secretary of Defense.

Those who do not study the past will repeat its errors; those who do
will find other ways to err. -- Charles Wold, Jr., Rand Corporation Economist

<=====================================================================>
< Dan Sorenson, z1...@exnet.iastate.edu, nobody else claims the above >
<"I'm sure I'd feel much worse if I weren't so heavily sedated." >
< -- M. McKean >
<=====================================================================>

Jos Horsmeier

unread,
Sep 24, 1991, 7:30:20 AM9/24/91
to
|Murphy's First Corollary:
|
|If Murphy's Law can go wrong, it will.
|
|
|Murphy's Second Corollary:
|
|If Murphy's First Corollary can go wrong, it will.
|
|
|
|(Murphy gave up after this. :-)
|
Mrs. Murphy's law:

My husband is an optimist ...

Jos (j...@and.nl)

David Bolen

unread,
Sep 24, 1991, 2:19:16 PM9/24/91
to
In article <1991Sep22....@idaho.uucp> rhod...@idaho.uucp (III) writes:

In article <1991Sep22....@idaho.uucp> rhod...@idaho.uucp (III) writes:

>Does any happen to have a list a Murphy-law like sayings
>for computer programming (I'm sure you've seen the posters)?

Well, since I've got two such posters on my wall, and I've wanted them online
for some time now, I might as well give it a shot. They aren't all directly
related to programming, but most are and the others are humorous anyway:


Poster 1:
--------

Murphy's Computer Law
1. Murphy Never Would Have Used One
2. Murphy Would Have Loved Them
Bove's Theorem
The remaining work to finish in order to reach your goal increases
as the deadline approaches.
Brooks' Law


Adding manpower to a late software project makes it later.
Canada Bill Jones' Motto
It's morally wrong to allow naive end users to keep their money.
Cann's Axiom

When all else fails, read the instructions.

Clarke's Third Law
Any sufficiently advanced technology is indistinguishable from magic.
Deadline-Dan's Demo Demonstration


The higher the "higher-ups" are who've come to see your demo, the

lower your chances are of giving a successful one.
Deadline-Dan's Demon


Every task takes twice as long as you think it will take. If you
double the time you think it will take, it will actually take four
times as long.

Demian's Observation
There is always one item on the screen menu that is mislabeled and


should read "ABANDON HOPE ALL YE WHO ENTER HERE".

Dr. Caligari's Come-back
A bad sector disk error occurs only after you've done several hours
of work without performing a backup.
Estridge's Law


No matter how large and standardized the marketplace is, IBM can
redefine it.

Finagle's Rules:
1. To study an application best, understand it thoroughly before you
start.
2. Always keep a record of data. It indicates you've been working.
3. Always draw your curves, then plot the reading.
4. In case of doubt, make it sound convincing.
5. Program results should always be reproducible. They should all


fail in the same way.

6. Do not believe in miracles. Rely on them.
Franklin's Rule


Blessed is the end user who expects nothing, for he/she will not be
disappointed.

Gilb's Laws of Unreliability
1. At the source of every error which is blamed on the computer you
will find at least two human errors, including the error of blaming
it on the computer.
2. Any system which depends on 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.
Gummidge's Law


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

Harp's Corollary to Estridge's Law


Your "IBM PC-compatible" computer grows more incompatible with every
passing moment.

Heller's Law


The first myth of management is that it exists.

Hinds' Law of Computer Programming
1. Any given program, when running, is obsolete.
2. If a program is useful, it will have to be changed.
3. If a program is useless, it will have to be documented.
4. Any given program will expand to fill all available memory.
5. The value of a program is proportional to the weight of its output.
6. Program complexity grows until it exceeds the capability of the


programmer who must maintain it.

7. Make it possible for programmers to write programs in English, and


you will find that programmers cannot write in English.

Hoare's Law of Large Programs


Inside every large program is a small program struggling to get out.

The Last One's Law of Program Generators


A program generator creates programs that are more "buggy" than the
program generator.

Meskimen's Law


There's never time to do it right, but always time to do it over.

Murphy's Fourth Law


If there is a possibility of several things going wrong, the one that
will cause the most damage will be the one to go wrong.

Murphy's Law of Thermodynamics


Things get worse under pressure.

Ninety-Ninety Rule of Program Schedules


The first ninety percent of the task takes ninety percent of the time,

and the last ten percent take the other ninety percent.
Nixon's Theorem


The man who can smile when things go wrong has thought of someone he
can blame it on.

Nolan's Placebo


An ounce of image is worth a pound of performance.

Osborn's Law


Variables won't, constants aren't.

O'Toole's Commentary on Murphy's Law
Murphy was an optimist.
Peer's Law


The solution to a problem changes the problem.

Rhodes' Corollary to Hoare's Law


Inside every complex and unworkable program is a useful routine
struggling to be free.

Robert E. Lee's Truce


Judgement comes from experience; experience comes from poor judgement.

Sattinger's Law


It works better if you plug it in.

Shaw's Principle
Build a system that even a fool can use, and only a fool will want to
use it.
Snafu Equations
1. Given any problem containing N equations, there will be N+1
unknowns.
2. An object or bit of information most needed will be least available.
3. Any device requiring service or adjustment will be least accessible.
4. Interchangeable devices won't.
5. In any human endeavor, once you have exhausted all possibilities
and fail, thee will be one solution, simple and obvious, highly
visible to everyone else.
6. Badness comes in waves.
Thoreau's Theories of Adaptation
1. After months of training and you finally understand all of a


program's commands, a revised version of the program arrives with
an all-new command structure.

2. After designing a useful routine that gets around a familiar "bug"
in the system, the system is revised, the "bug" is taken away, and


you're left with a useless routine.

3. Efforts in improving a program's "user friendliness" invariable


lead to work in improving user's "computer literacy."

4. That's not a "bug", that's a feature!
Weinberg's Corollary


An expert is a person who avoids the small errors while sweeping on
to the grand fallacy.

Weinberg's Law


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

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


As soon as a still-to-be-finished computer task becomes a
life-or-death situation, the power fails.


Poster 2:
--------

Laws of Computer Programming
(see Hinds' Law of Computer Programming in poster 1)
Rules of Pratt
* If a severe problem manifests itself, no solution is acceptable
unless it is involved, expensive, and time consuming.
* Sufficient monies to do the job correctly the first time are not
available; however, ample funds are much more easily obtained for
repeated revisions.
Grosch's Law
* Computing power increases as the square of the cost increases.
If you want to do it twice as cheaply you have to do it four times
as fast.
* Twenty per cent of the components account for eighty percent of the
cost, and so forth.
Weinberg's Law
(see poster 1)
Hare's Law of Large Programs
(see Hoare's Law of Large Programs in poster 1)
Turnaucka's Law
* The attention span of a computer is only as long as its electrical
cord.
Fallible Men Design Fallible Computers
A computer program does what you tell it to do, not what you want it
to do.
Troutman's Programming Laws
* If a test installation functions perfectly, all subsequent systems
will malfunction.
* Not until a program has been in production for at least six months
will the most harmful error then be discovered.
* Job control cards that cannot be arranged in improper order will be.
* Interchangeable tapes won't.
* 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.
* Machines work, people should think.
Golub's Laws of Computerdom
* A carelessly planned project takes three times longer to complete
tan expected; a carefully planned project will take only twice
as long.
* The effort required to correct the error increases geometrically
with time.
* Project teams detest weekly progress reporting because it so


vividly manifests their lack of progress.

Hunt's Law of Suspense
If any work has a suspense date on it, that work will be completed as
close to the suspense date as possible regardless of how far in
advance it was programmed.
-Unnamed-
Civilization Advances by extending the number of important operations
which we can do without thinking of them.
-Unnamed-
One good reason why computers can do more work than people is that
they never have to stop and answer the phone.
Gilb's Law of Reliability
(A little different than in poster 1)
* Computers are unreliable but humans are even more unreliable.
* At the source of every error which is blamed on the computer you
will find at least two human errors including the error of blaming
it on the computer.
* Any system which depends on human reliability is unreliable
* A system tends to grow in complexity rather than simplification,
until the resulting unreliability becomes intolerable.
* Fuzzy project objectives are used to avoid the embarrassment of
estimating the corresponding costs.
Landau's Programming Paradox
* The best programmer has to be someone.
* The more humanlike a computer becomes the less time it spends
computing and the more time it spends doing more humanlike work.
* A software committee of one is limited by its own horizon and will
on specify that far.
Extended Epstein-Heisenberge Principle
In a program atmosphere, only two of the three existing measurements
can be measured simulatneously. The measurements are program, time,
and resources ($):
* If one knows what the task is, and there is a time limit allows
for the completion of the task, then one cannot guess how much
it will cost.
* If the time and resources ($) are clearly defined, then it is
impossible to know what part of the program will be performed.
* If you are given a clearly defined program goal and a definite
amount of money which has been calculated to be necessary for the
completion of the task, one cannot predict if and when the goal
will be reached.
* If one is lucky enough and can accurately define all three
measurements, then what one deals with is not in the realms of
programming.
Gallaois' Revelation
If you put tomfollery in a computer nothing comes out but tomfollery.
But this tomfoolery, having passed through a very expensive machine,
is somehow enobled and none dare criticize it.
Bradley's Bromoide
If computers get to powerful, we can organize them into a committee -
that will do them in.

It's interesting that many of these seem to clearly fall into the folklore
category - the same named items aren't necessarily even the same between
my two posters :-)

Anyway, there are a few for you..

--
-- David
--
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db...@ans.net /
| Advanced Network & Services, Inc. \ Phone: (914) 789-5327 |
/ 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
\-----------------------------------------------------------------------/

Peter David THOMPSON

unread,
Sep 25, 1991, 12:56:56 AM9/25/91
to

>John West
Well, let me assure you that stuctured constants (or typed constants) are
just preinitialised variables ("typed constants are just variables with
a constant value" - TP5.5 reference guide.) . So don't be too suprised, ok?
I was, until I looked it up....
BTW, please don't accuse me of being a TP guru. It's just that our
group project is in TP (It was either that or a Mac project... I don't
like computers that FORCE you to use the mouse).
Remeber:
Only Amiga makes it possible;
only Mac makes it necessary.

/******************************Disclaimer*********************************
** My opinion(s) are wholly my own (No-one else wants them) and is(are) **
** independant of any part of the University of Melbourne, Australia. **
******* Followups to p...@mundil.cs.mu.OZ.AU; flames to /dev/null. *******/
NOTE: This sentence does not in fact have the property it claims it lacks.

Ken Yap

unread,
Sep 25, 1991, 2:16:57 AM9/25/91
to
Not to forget

Murphy's Nth law: Don't mess with Mrs. Murphy

Forgot which poster I saw this on.

Ewan Benson

unread,
Sep 24, 1991, 3:31:17 AM9/24/91
to
In article <1991Sep22....@idaho.uucp> rhod...@idaho.uucp (III) writes:
>Does any happen to have a list a Murphy-law like sayings
>for computer programming (I'm sure you've seen the posters)?
>

Here's some I got of the net about a year ago....
---

From pyrltd!ukc!mcvax!unido!altger!snoopy Wed Dec 14 08:24:39 GMT 1988


1. The remaining work to finish in order to reach your goal increases as the
deadline approaches.
2. Adding manpower to a late software project makes it later.
3. It's morally wrong to allow naive end users to keep their money.
4. When all else fails, read the instructions.
5. Any suffiently advanced technology is indistinguishable from magic.
6. The higher the "higher-ups" are who've come to see your demo, the lower


your chances are of giving a successful one.

7. Every task takes twice as long as you think it will take. If you double


the time you think it will take, it will actually take four times as
long.

8. There is always one item on the screen menu that is mislabeled and


should read "ABANDON HOPE ALL YE WHO ENTER HERE".

9. A bad sector disk error occurs only after you've done several hours of


work without performing a backup.

10. No matter how large and standardized the marketplace is, IBM can
redefine it.
11. To study an application best, understand it thoroughly before you start.
12. Always keep a record of data. It indicates you've been working.
13. Always draw your curves, then plot the reading.
14. In case of doubt, make it sound convincing.
15. Program results should always be reproducible. They should all fail in
the same way.
16. Do not believe in miracles. Rely on them.
17. Blessed is the end user who expects nothing, for he/she will not be dis-
appointed.
18. At the source of every error which is blamed on the computer you will


find at least two human errors, including the error of blaming it on the
computer.

19. Any system which depends on human reliability is unreliable.
20. Undetectable errors are infinite in variety, in contrast to detectable


errors, which by definition are limited.

21. Investment in reliability will increase until it exceeds the probable
cost of errors or until someone insists on getting some useful work
done.
22. The amount of expertise varies in inverse proportion to the number of


statements understood by the general public.

23. Your "IBM PC-compatible" computer grows more incompatible with every
passing moment.
24. The first myth of management is that it exists.
25. Any give program, when running, is obsolete.
26. If a program is useful, it will have to be changed.
27. If a program is useless, it will have to be documented.
28. Any given program will expand to fill all available memory.
29. The valueof a program is proportional to the weight of its output.
30. Program complexity grows until it exceeds the capability of the


programmer who must maintain it.

31. Make it possible for programmers to write programs in English, and you


will find that programmers cannot write in English.

32. Inside every large program is a small program struggling to get out.
33. A program generator creates programes that are more buggy than the
program generator.
34. There's never time to do it right, but always time to do it over.
35. If there is a possibility of several things going wrong, the one that


will cause the most damage will be the one to go wrong.

36. Things get worse under pressure.
37. The first ninety percent of the task takes ninety percent of the time,


and the last ten percent take the other ninety percent.

38. The man who can smile when things go wrong has thought of someone he can
blame it on.
39. An ounce of image is worth a pound of performance.
40. Variables won't, constants aren't.
41. Murphy was an optimist.
42. The solution to a problem changes the problem.
43. Inside every complex and unworkable program is a useful routine
struggling to be free.
44. Judgement comes from experience; experience comes from poor judgement.
45. It works better if you plug it in.
46. Build a system that even a fool can use, and only a fool will wnat to
use it.
47. Give any problem containing N equations, there will N+1 unknowns.
48. An object or bit of information most needed will be least available.
49. Any device requiring service or adjustment will be least accessible.
50. Interchangeable devices won't.
51. In any human endeavor, once you have exhausted all possibilities and
fail, there will be one solution, simple and obvious, highly visible to
everyone else.
52. Badness comes in waves.
53. After months of training and you finally understand all of a program's


commands, a revised version of the program arrives with an all-new
command structure.

54. After designing a useful routine that gets around a familiar bug in the


system, the system is revised, the bug is taken away, and you're left
with a useless routine.

55. Efforts in improving a program's "user friendliness" invariably lead to


work in improving user's "computer literacy".

56. That's not a bug, that's a feature!
57. An expert is a person who avoids the small errors while sweeping on to
the grand fallacy.
58. If builders built buildings the way programmers write programs, then the
first woodpecker that cames along would destroy civilization.
59. Once you open a can of worms, the only way to recan them is to use a
larger can.
60. As soon as a still-to-be-finished computer task becomes a life-or-death
situation, the power fails.
--

Unfortunately they are all true.

Cheers

Ewan 'bring back the Cambridge Mk 14' Benson
--
Ewan Benson Lucas Powertrain Systems,
Phoenix Way,
Mail: ew...@eg.lucasauto.co.uk Cirencester,
Phone: 0285 657981 x250 England (Unfortunately!)

P. Harrison

unread,
Sep 25, 1991, 9:35:51 AM9/25/91
to
This came from "/uusr/games/fortune":
(I forget the name)

X's law:
Any computer project will take twice as long as you think it will
even when you take into account X's law...


Steve Lamont

unread,
Sep 25, 1991, 1:02:03 PM9/25/91
to
In article <kdsiju...@mthvax.cs.miami.edu> ya...@mthvax.cs.miami.edu (Yanek Martinson) writes:
>IBM POLLYANNA PRINCIPLE
>
> Machines should work. People should think.

... I don't know if he was the originator of this line, but I've heard
Richard Hamming say this more than once. Sounds like a Hammingism.

spl
--
Steve Lamont, SciViGuy -- (619) 534-7968 -- s...@dim.ucsd.edu
UCSD Microscopy and Imaging Resource/UCSD Med School/La Jolla, CA 92093-0608
"Water for people, not landscaping"
- Bumper sticker seen in Southern California

Matthias Urlichs

unread,
Sep 25, 1991, 5:04:56 AM9/25/91
to
In alt.folklore.computers, article <65...@inews.intel.com>,

bhou...@hopi.intel.com (Blair P. Houghton) writes:
<
< "data expands to fill the available space."
<
Wrong. Real-world experience has shown that the data expands to 10% beyond
available space.

In the real world, this phenomenon is known as the Law of Inches (anything
you fit into anything is half an inch too big. Alternately, the container is
half an inch too small. You get one inch when you add the problems :-)
but data aren't as well-behaved.

--
Matthias Urlichs -- url...@smurf.sub.org -- url...@smurf.ira.uka.de /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany -- +49-721-9612521 \o)/

David H. Thornley

unread,
Sep 25, 1991, 1:27:47 PM9/25/91
to
In article <mdkc8_=@smurf.sub.org> url...@smurf.sub.org (Matthias Urlichs) writes:
>
>Murphy's law can't be inverted, recursed, or iterated. It can only be
>reiterated, which is what we're doing here right now. ;-)

Wrong. I've cursed Murphy's law, and I've cursed it again.

Therefore, Murphy's law can be recursed.

DHT

Gym Z. Quirk

unread,
Sep 25, 1991, 2:07:27 PM9/25/91
to
Hmmm...havn't seen this one yet...

Zymurgh's Law of Entymology:

"There's always one more bug."
--
Capt. Gym Z. Quirk (Known to some as Taki Kogoma) tko...@triton.unm.edu
Veteran of the "Grand sf-lovers fiasco" of July '91-???.
Secret Master of rec.arts.startrek
-= Insert witty quote here =-

Scott C. Kennedy

unread,
Sep 25, 1991, 12:30:39 PM9/25/91
to
In article <1991Sep24.0...@massey.ac.nz>, ne...@massey.ac.nz (USENET News System) writes:
|> Thats not a bug, but a feature.

Along this vein, while a physicist (Paul FInk) and I were working on a
project on a very tight schedule, management asked how long it would take to
debug our work. To which Paul replied, "Bugs? We don't have time to put in
bugs. If you want some bugs, it will take at least another six months." Ever
since then, I can't keep a straight face when debugging my own code.

------------------------------------------------------------------------------
Scott C. Kennedy (s...@watson.ibm.com) | This post does not reflect the intent
Distributed High Performance Computing | or actions of my employer, and their
IBM Thomas J. Watson Research Facility | actions don't reflect mine either.:)
------------------------------------------------------------------------------
****************** CAUTION: DEADLIEST JOKE IN THE WORLD **********************
"Venn ist das nurnstuck git und Slotermeyer?
Ja! Beigerhund das oder die Flipperwaldt gersput!"

The Polymath

unread,
Sep 24, 1991, 9:21:29 PM9/24/91
to

Murphy's law (the general case):

Anything that can happen will happen.

Finagle's commentary on Murphy's law:

Murphy was an optimist.

Finagle's laws of dynamic negatives:

The perversity of the universe tends towards a maximum.

Anything that can go wrong will go wrong.

Sturgeon's law:

90% of _everything_ is crap.


The three laws of thermodynamics:

1. You can't win.
2. You can't break even.
3. You can't get out of the game.

It has been noted that most major economic/religious/philosophical systems
assume the violation of one of the above laws. For example:

Capitalism assumes you can win.

Socialism and Communism assume you can break even.

Judeo-Christianity assumes you can get out of the game.


Someone's law of dieting:

That which is not illegal, immoral or fattening will cause cancer
in rats.

[The above is off the top of my head. I've got a pile more somewhere,
but they're not conveniently on line at the moment.]

--
The Polymath (aka: Jerry Hollombe, M.A., CDP, aka: holl...@ttidca.tti.com)
Head Robot Wrangler at Citicorp Turn the rascals out!
3100 Ocean Park Blvd. (213) 450-9111, x2483 No incumbents in '92!
Santa Monica, CA 90405 {rutgers|pyramid|philabs|psivax}!ttidca!hollombe

Matthias Urlichs

unread,
Sep 25, 1991, 5:10:18 AM9/25/91
to
In alt.folklore.computers, article <1991Sep24.0...@bronze.ucs.indiana.edu>,

jkon...@bronze.ucs.indiana.edu (Jon Konrath) writes:
< In article <1991Sep24.0...@ux1.cso.uiuc.edu> rka2...@uxa.cso.uiuc.edu (Rubio) writes:
< >Murphy's First Corollary:
< >If Murphy's Law can go wrong, it will.
< >
< >Murphy's Second Corollary:
< >If Murphy's First Corollary can go wrong, it will.
< >
< >(Murphy gave up after this. :-)
<
< But what if Mr. Murphy learned scheme, and implemented it with good recursion?
<
Doesn't work, for the same reason that if you wash your car in order to make
it rain you'll realize that you forgot to close one of the car's windows.
I.e., something else will go wrong instead.

Murphy's law can't be inverted, recursed, or iterated. It can only be
reiterated, which is what we're doing here right now. ;-)

Norman Diamond

unread,
Sep 26, 1991, 3:39:30 AM9/26/91
to
In article <fdk...@smurf.sub.org> url...@smurf.sub.org (Matthias Urlichs) writes:
>In alt.folklore.computers, article <65...@inews.intel.com>,
> bhou...@hopi.intel.com (Blair P. Houghton) writes:
>> "data expands to fill the available space."
>Wrong. Real-world experience has shown that the data expands to 10% beyond
>available space.
Wrong. Real-world experience has shown that the data expand to 11.111...%
beyond the available space, with help from a root user. Example:
csh> df
Filesystem Total kbytes kbytes %
node kbytes used free used Mounted on
/dev/rz0a 62527 62527 -6252 111% /
--
Norman Diamond dia...@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
signature, n.: acm special interest group on studies of the real world.

Rogier Wolff

unread,
Sep 26, 1991, 10:26:08 AM9/26/91
to
cmp...@sys.uea.ac.uk (P. Harrison) writes:

X = Hofstadter (Douglas R.), author of "Godel, Escher, Bach".
--
EMail: wo...@duteca.et.tudelft.nl ** Tel +31-15-783644 or +31-15-142371
* God does not play dice! -Albert Einstein. *
* True. How could he play dice if he doesn't exist? -Me. *

Eric Peterson

unread,
Sep 26, 1991, 9:30:02 AM9/26/91
to
cmp...@sys.uea.ac.uk (P. Harrison) writes:

That is probably a variant of this, from _Metamagical_Themas_ by Douglas
Hofstadter:

Hofstadter's Law:
It always takes longer than you think, even when you take into
account Hofstadter's Law.

Eric
--
Eric Peterson <> epet...@encore.com <> uunet!encore!epeterson
Encore Computer Corp. * Ft. Lauderdale, Florida * (305) 587-2900 x 5208
"The heat and light from the sun are caused by the nuclear reaction between
hydrogen, helium, oxygen, estrogen, AND hair." - They Might Be Giants

scott.forbes

unread,
Sep 26, 1991, 10:52:29 AM9/26/91
to
Here's another one, and I can't remember where I first saw it:

"A computer can make more mistakes in ten seconds
than humans can make in a thousand years."

==== Scott Forbes AT&T Network Software Center
=---==== for...@toolserv.att.com #include <disclaimer.h>
=-----====
==---===== "Only a fool looks foolish,
======== and only a fool twice over worries about it."
==== -- Chiun, Master of Sinanju

Klaus Ole Kristiansen

unread,
Sep 26, 1991, 4:12:36 AM9/26/91
to
cmp...@sys.uea.ac.uk (P. Harrison) writes:

>

Hoffstaedter's (sp?) Law: everything takes longer than you think
even if you take Hoffstaedter's law
law into account.


Remember also the 90/90 rule: 10% of the project takes
90% of the time, the other 90% of the project takes the
other 90% of the time.

Actually both X's law and the 90/90 rule are too
optimistic. A real-life survey of a large number
of OR projects gave an actuel time/expected time
ratio very close to pi (3.14 ...)

Klaus O K

Rich Greenberg

unread,
Sep 27, 1991, 12:30:19 AM9/27/91
to
My favorite along these lines is"

"A computer is a very stupid machine...
It makes every mistake you tell it to"

--
Disclaimer: The above writings are the ramblings of one human being
and have nothing what-so-ever to do with Locus Computing Corp.
---> Rich Greenberg, ri...@locus.com TinsleTown, USA 213-337-5904
Located in Inglewood, Ca, a small city completely contained within Los Angeles

house ron

unread,
Sep 27, 1991, 8:06:38 AM9/27/91
to
s...@watson.ibm.com (Scott C. Kennedy) writes:

>****************** CAUTION: DEADLIEST JOKE IN THE WORLD **********************
>"Venn ist das nurnstuck git und Slotermeyer?
> Ja! Beigerhund das oder die Flipperwaldt gersput!"

Yes, and we know where you got it from!

--
Regards,

Ron House. (s64...@zeus.usq.edu.au)
(By post: Info Tech, U.C.S.Q. Toowoomba. Australia. 4350)

Hodge Podge

unread,
Sep 27, 1991, 8:37:47 PM9/27/91
to

>Here's another one, and I can't remember where I first saw it:

> "A computer can make more mistakes in ten seconds
> than humans can make in a thousand years."


Shouldn't it read:
A Computer can make more mistakes in 10 seconds
the a human can fix in ten years.
^^^

Just an idea of course.


--
Gene Moreau, University of Manitoba.
ummo...@ccu.umanitoba.ca
"Are saying I'm redundant, that I repeat my self,
that I say things over and over?"

Redmond English

unread,
Sep 26, 1991, 8:56:31 PM9/26/91
to
The first 90% of a project takes 90% of the available time.
The last 10% takes the other 90% of the time.

Peter da Silva

unread,
Sep 27, 1991, 7:15:41 AM9/27/91
to
dnic...@ceilidh.beartrack.com (Don Nichols (DoN.)) writes:
> "If builders built buildings the way programmers write programs, the
> first woodpecker to come along would destroy civilization" (Weinberger's
> law, I think)

If builders built buildings the way programmers write programs you'd be
able to buy a nice colonial split-level for 25c at the corner store.
--
-- Peter da Silva. 3D0G `-_-'
-- Taronga Park BBS.
-- +1 713 568 0480|1032 2400/n/8/1.
-- "Have you hugged your wolf today?"

Peter da Silva

unread,
Sep 27, 1991, 7:33:49 AM9/27/91
to
gu...@uniwa.uwa.oz.au (D John McKenna) writes:
> Try passing a structured constant to a var parameter in Turbo Pascal.

Turbo Pascal doesn't *have* constants. It has initialised variables that
it calls constants.

(It's also not Pascal, really)

Don Nichols (DoN.)

unread,
Sep 26, 1991, 9:23:50 PM9/26/91
to
In article <29...@ttidca.TTI.COM> holl...@ttidca.TTI.COM (The Polymath) writes:

[ ... ]

>Someone's law of dieting:
>
> That which is not illegal, immoral or fattening will cause cancer
> in rats.

That doesn't prove anything! Aren't laboratory rats designed to
develop cancer when exposed to ANYTHING, even contempt? (And especially
when exposed to Muzak.)
--
Donald Nichols (DoN.) | Voice (Days): (703) 664-1585 (Eves): (703) 938-4564
D&D Data | Email: <dnic...@ceilidh.beartrack.com>
I said it - no one else | <dnic...@ceilidh.aes.com>
--- Black Holes are where God is dividing by zero ---

THE Upholder of Truth

unread,
Sep 27, 1991, 10:25:23 AM9/27/91
to
dnic...@ceilidh.beartrack.com (Don Nichols (DoN.)) writes:
> holl...@ttidca.TTI.COM (The Polymath) writes:
>>Someone's law of dieting:
>>
>> That which is not illegal, immoral or fattening will cause cancer
>> in rats.
>
> That doesn't prove anything! Aren't laboratory rats designed to
>develop cancer when exposed to ANYTHING, even contempt? (And especially
>when exposed to Muzak.)

Could it be that cancer is linked to lab rats?

--
The Upholder of Truth The Flying Illini
jar4...@uxa.cso.uiuc.edu (BSD mail) | | F-15E Strike Eagle
ran...@sumter.cso.uiuc.edu (NeXT mail) | ___ | (yeah, I wish)
----/___\----
I am not only ready to x______________( . )______________x
retract this, but also *|* | | \___/ | | *|*
deny I said anything. =) * 0 |__| |__| 0 *

Mark Brader

unread,
Sep 27, 1991, 4:17:39 PM9/27/91
to
> As for verification of Murphy's Laws in general. There was a blow-out on
> a North Sea Oil Rig in the 70's because a blow-out preventer had been
> installed upside down. The name of the chief engineer who installed it?
> A certain Mr Murphy, of course. "If anything can be installed upside
> down, it will"

From the Jargon File, release 2.9.6:

| Murphy's Law: prov. The correct, *original* Murphy's Law
| reads: "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."
| This is a principle of defensive design, cited here because it is
| usually given in mutant forms less descriptive of the challenges of
| design for lusers. For example, you don't make a two-pin plug
| symmetrical and then label it `THIS WAY UP'; if it matters which
| way it is plugged in, then you make the design asymmetrical (see
| also the anecdote under {magic smoke}).
|
| Edward A. Murphy, Jr. was one of the engineers on the rocket-sled
| experiments that were done by the U.S. Air Force in 1949 to test
| human acceleration tolerances. One experiment involved a set of
| 16 accelerometers mounted to different parts of the subject's body.
| There were two ways each sensor could be glued to its mount, and
| somebody methodically installed all 16 the wrong way around.
| Murphy then made the original form of his pronouncement, which the
| test subject (Major John Paul Stapp) quoted at a news conference a
| few days later.
|
| Within months `Murphy's Law' had spread to various technical
| cultures connected to aerospace engineering. Before too many years
| had gone by variants had passed into the popular imagination,
| changing as they went. Most of these are variants on "Anything
| that can go wrong, will"; this is sometimes referred to as
| {Finagle's Law}. The memetic drift apparent in these mutants
| clearly demonstrates Murphy's Law acting on itself!
--
Mark Brader, SoftQuad Inc., Toronto, utzoo!sq!msb, m...@sq.com
"I'm a little worried about the bug-eater," she said. "We're embedded
in bugs, have you noticed?" -- Niven, "The Integral Trees"

This article is in the public domain, including the Jargon File excerpt.

scott.forbes

unread,
Sep 27, 1991, 1:20:55 PM9/27/91
to
I had almost forgotten one of my favories, until Peter da Silva
(pe...@taronga.hackercorp.com) jarred my memory:

>If builders built buildings the way programmers write programs you'd be
>able to buy a nice colonial split-level for 25c at the corner store.

"If the automobile had followed the same development cycle as the computer,
a Rolls-Royce today would cost $100, get a million miles to the gallon, and
explode once a year, killing everyone inside."

D John McKenna

unread,
Sep 28, 1991, 12:51:55 AM9/28/91
to
r...@yrloc.ipsa.reuter.COM (Robert Bernecky) writes:

>"Figure out howl long it'll take, and multiply by two." (Significant
>pause) "The hard part is figuring how many times to multiply by two".

The one I heard was "double the number, then jump up to the next set of
units." So 2 weeks -> 4 months

John West
rejected by fish

Robert Bernecky

unread,
Sep 27, 1991, 12:28:21 AM9/27/91
to
Roger Moore (recipient of the Grace Murray Hopper Award for his work
on APL\360, and my first "boss" at I.P. Sharp) had this advice for
those who would dare to predict project completion dates:

"Figure out howl long it'll take, and multiply by two." (Significant
pause) "The hard part is figuring how many times to multiply by two".

Hmm. This doesn't fit into folklore, since it's firsthand, but
if someone else tells it to someone else...

Robert Bernecky r...@yrloc.ipsa.reuter.com bern...@itrchq.itrc.on.ca
Snake Island Research Inc (416) 368-6944 FAX: (416) 360-4694
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9
Canada

Klaus Ole Kristiansen

unread,
Sep 28, 1991, 4:26:07 AM9/28/91
to
s...@watson.ibm.com (Scott C. Kennedy) writes:

>****************** CAUTION: DEADLIEST JOKE IN THE WORLD **********************
>"Venn ist das nurnstuck git und Slotermeyer?
> Ja! Beigerhund das oder die Flipperwaldt gersput!"

You brute! Think of all the poor German reades you've killed!
How fortunate that I have forgotten most of the German I
learned in school.

Klaus O K

Oh yes, I almost forgot: :-)

RAMontante

unread,
Sep 28, 1991, 3:09:05 PM9/28/91
to
Any computer-related question is either important or unimportant:
Important questions receive no answer.
Unimportant questions receive unlimited answers.

Dave Huang

unread,
Sep 28, 1991, 4:29:10 PM9/28/91
to
>> As for verification of Murphy's Laws in general. There was a blow-out on
>> a North Sea Oil Rig in the 70's because a blow-out preventer had been
>> installed upside down. The name of the chief engineer who installed it?
>> A certain Mr Murphy, of course. "If anything can be installed upside
>> down, it will"

How very true... And I guess this goes with the "Stupid Users" thread
too: My friend used to work an an Apple dealer, and he told me that
one day, this guy brought his Mac 512 in complaining that he couldn't
get the printer to work. It turns out that he had plugged the DB-9
connector upside down! (A rather impressive feat, you must admit...)

I guess this says something about Mac users? :-)
--
David Huang |
Internet: da...@ccwf.cc.utexas.edu | "Microwaves: They're not just
UUCP: ...!ut-emx!ccwf.cc.utexas.edu!daveh | for cooking anymore."
America Online: DrWho29 |

Don Stokes

unread,
Sep 25, 1991, 5:15:11 AM9/25/91
to
I'm surprised no-one's mentioned Hofstadter's Law:

"Every project takes longer than expected, even when Hofstadter's
Law is take into account."


--
/ / Don Stokes, ZL2TNM (DS555) d...@zl2tnm.gp.co.nz (home)
/GP/ VMS Sys. Prog., Unix-weenie-in-training d...@gp.co.nz (work)
/ / GP Print Ltd, Wellington, New_Zealand +64 4 4965 681

D John McKenna

unread,
Sep 29, 1991, 2:46:21 AM9/29/91
to
kl...@diku.dk (Klaus Ole Kristiansen) writes:

>s...@watson.ibm.com (Scott C. Kennedy) writes:

>>****************** CAUTION: DEADLIEST JOKE IN THE WORLD **********************

>>"V*n* i*t *as n*rns*u*k gi* u*d *lo*erm*y**?
>> *a! B*i*erh*n* d*s **e* d*e F*ip*erwa*dt *e*sput*"

<Joke censored to protect the Germans>

>You brute! Think of all the poor German reades you've killed!
>How fortunate that I have forgotten most of the German I
>learned in school.

>Klaus O K

>Oh yes, I almost forgot: :-)

HELP! SAVE US! Its alt.fan.monty-python! Running out of MBytes in their
own group, they've come to invade ours! HELP!

John West

Gym Z. Quirk

unread,
Sep 29, 1991, 10:26:27 PM9/29/91
to

Hmmm...I guess this explains the nature of USENET pretty well...;-)

--
Capt. Gym Z. Quirk (Known to some as Taki Kogoma) tko...@triton.unm.edu
Veteran of the "Grand sf-lovers fiasco" of July '91-???.
Secret Master of rec.arts.startrek
-= Insert witty quote here =-

Steve Lamont

unread,
Sep 30, 1991, 7:58:08 PM9/30/91
to
In article <1991Sep27....@cbfsb.att.com> for...@cbnewsf.cb.att.com (scott.forbes) writes:
>I had almost forgotten one of my favories, until Peter da Silva
>(pe...@taronga.hackercorp.com) jarred my memory:
>
>>If builders built buildings the way programmers write programs you'd be
>>able to buy a nice colonial split-level for 25c at the corner store.
>
>"If the automobile had followed the same development cycle as the computer,
>a Rolls-Royce today would cost $100, get a million miles to the gallon, and
>explode once a year, killing everyone inside."

... a collegue of mine at the San Diego Supercomputer Center (who
wishes to remain anonymous for his own bizarre reasons) has sent me
this for posting:

I don't know if I agree with them or not.

If they compare it to C Programmers, you'd get something a bit more
junky that you can live in most of the time, that looks almost exactly
like every other house on the block (except for the occasional
non-standard mod). Your house would only rest properly on certain
lots and not others.

Most of the power outlets would be recognizible, but you could only
buy your lights, etc. from one vendor. You'd have to have a large
number of adaptors on hand to handle non-vendor supported appliances.

Your two car garage would only fit one car (Chevy Chevette). The
other slot would have to remain empty because no other car fits it
currently, but one is promissed for 1st quarter next year or the year
after that.

Then think about the problems landscaping...

Home improvments/upgrades would always take much longer than expected
and cost a lot more than you wanted to pay. And talk about a shortage
of storage space! You'd never have enough storage.

spl (the p stands for
posting for a friend is
not at all like showering
with a friend)
--
Steve Lamont, SciViGuy -- (619) 534-7968 -- s...@dim.ucsd.edu
UCSD Microscopy and Imaging Resource/UCSD Med School/La Jolla, CA 92093-0608
"Water for people, not landscaping"
- Bumper sticker seen in Southern California

Steve Lamont

unread,
Sep 30, 1991, 8:01:53 PM9/30/91
to
In article <1991Sep27....@cbfsb.att.com> for...@cbnewsf.cb.att.com (scott.forbes) writes:
>I had almost forgotten one of my favories, until Peter da Silva
>(pe...@taronga.hackercorp.com) jarred my memory:
>
>>If builders built buildings the way programmers write programs you'd be
>>able to buy a nice colonial split-level for 25c at the corner store.
>
>"If the automobile had followed the same development cycle as the computer,
>a Rolls-Royce today would cost $100, get a million miles to the gallon, and
>explode once a year, killing everyone inside."

... a collegue of mine at the San Diego Supercomputer Center (who

Peter da Silva

unread,
Oct 1, 1991, 7:46:02 AM10/1/91
to
s...@alex.uucp (Steve Lamont) writes:
> If they compare it to C Programmers, [...]

Sure he didn't mean "X-windows" programmers? It sure sounds like he's
discussing Motif-versus-OpenLook.

Steve Lamont

unread,
Oct 1, 1991, 11:09:55 AM10/1/91
to
In article <1991Sep27....@cbfsb.att.com> for...@cbnewsf.cb.att.com (scott.forbes) writes:
>I had almost forgotten one of my favories, until Peter da Silva
>(pe...@taronga.hackercorp.com) jarred my memory:
>
>>If builders built buildings the way programmers write programs you'd be
>>able to buy a nice colonial split-level for 25c at the corner store.
>

Steve Lamont

unread,
Oct 1, 1991, 10:57:51 AM10/1/91
to
In article <1991Sep27....@cbfsb.att.com> for...@cbnewsf.cb.att.com (scott.forbes) writes:
>I had almost forgotten one of my favories, until Peter da Silva
>(pe...@taronga.hackercorp.com) jarred my memory:
>
>>If builders built buildings the way programmers write programs you'd be
>>able to buy a nice colonial split-level for 25c at the corner store.
>

with a friend)Newsgroups: alt.folklore.computers
Subject: Re: Murphy's Laws for programming ?
Summary:
Expires:
References: <1991Sep23....@ceilidh.beartrack.com> <HID...@taronga.hackercorp.com> <1991Sep27....@cbfsb.att.com>
Sender:
Followup-To:
Distribution:
Organization: University of Calif. San Diego Microscope and Imaging Resource
Keywords:

In article <1991Sep27....@cbfsb.att.com> for...@cbnewsf.cb.att.com (scott.forbes) writes:
>I had almost forgotten one of my favories, until Peter da Silva
>(pe...@taronga.hackercorp.com) jarred my memory:
>

>>If builders built buildings the way programmers write programs you'd be
>>able to buy a nice colonial split-level for 25c at the corner store.
>

Blair M. Burtan

unread,
Oct 2, 1991, 1:08:02 PM10/2/91
to
See my .sig
--
+---------------------------------------------+
+ "Software is like entropy. +
+ It weighs nothing and always increases." +
+ +
+ Blair M. Burtan: be...@bucsf.bu.edu +
+---------------------------------------------+

IC...@asuacad.bitnet

unread,
Oct 2, 1991, 1:34:22 PM10/2/91
to
I picked up on this a little late, so I am surprised that there are still
a couple of my favorites still left.
Troutman's Second Programming Postulate:
Profanity is the one language all programmers know best.

Dick Youngquist's Law:
There are two types of perforations on a form - Too tight or too loose.

Richard Pottorff

unread,
Oct 7, 1991, 7:58:32 PM10/7/91
to
Pottorff's Law of Engineering Inertia:

Nothing usefull is ever accomplished until the hassle of not doing it
exceeds the hassle of doing it.

Surprisingly, I made that one up.

Ramblin'

John Hughes

unread,
Oct 9, 1991, 4:46:57 PM10/9/91
to

Ramblin'

Yes, but it's wrong. From my experience nothing gets done untile the
hassle of not doing it is some factor times the hassle of doing it.
The factor seems to be between ten and a hundred. (The Hughes's
laziness modification to Pottorff's Law).
--
John Hughes, | You can think of _Tyranosaurus_rex_
11 rue Castex, | as the 4 tonne road runner from HELL!
F-75004 Paris, FRANCE. | -- B. Bakker, Colorado University.

0 new messages