LAWS OF COMPUTING
Classic Humour item which turned up among some of my old university BSc Software Engineering notes. Many thanks to those who have emailed me with variations and additions to this page.

HARDWARE/SOFTWARE PARADIGM:
A program is a device to show up hardware faults; hardware is the equipment used to show up software faults.

A bad workman blames his tools; a Systems Analyst chooses from: the hardware, the software, the manual, the operating system, the interface, the peripherals, the ambient temperature, the night shift, the day shift, operators, programmers, BT, Mercury, the customer's specification, fluctuations in the power supply, those Taiwan chips, that last pint with the supplier's sales engineer

DATACOMMS COROLLARIES
Jobs involving comms will be delayed for an unspecifiable time because:
a) Misunderstanding of the precise protocol requirements
b) Lack of suitable international agreement on protocol
c) Both ends comply 100% with the protocol but the 'other' device still sends crud
d) Comms jobs, by definition, take longer

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

UTZ'S LAWS OF COMPUTER PROGRAMMING
1) Any given program, when 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) Any given program will expand to fit all available memory.
5) If a program is useless, it will be documented.
6) The value of a program is proportional to the volume of its output.
7) Program complexity grows until it exceeds the capability of the programmer who must maintain it.
8) Make it possible for programmers to write programs in English and you will find that programmers cannot write English.

MUNGBRIGHT'S LAWS
(Utz's Laws are sometimes attributed to Mungbright)
1) Not until the program has been released for six months will the most harmful error be discovered.
2) Machine independent code isn't.
3) Adding man power to a late software project makes it later.
4) The effort required to correct software problems increases geometrically with time.

LANDAU'S PROGRAMMING PARADOXES:
I) The world's best programmer has to be someone.
2) The more humanlike a computer becomes, the less it spends time computing and the more it spends time doing more humanlike work.
3) A software committee of one is limited by its own horizon and will specify software only that far.
4) When the system programmers declare the system works, it has worked and will work again some day.

DATA LOSS LAW:
Data is most urgently needed a week after it has been deleted.

WAIN'S CONCLUSION:
The only people making money these days are the ones selling computer paper.

GUTTERSON'S LAWS
Any programming project that begins well ends badly.
Any programming project that begins badly ends worse.

KLIENBRUNNER'S COROLLARIES
If a programming task looks easy its tough.
If a programming task looks tough it's damn-well impossible.

ROUGH ORDER OF MAGNITUDE LAW:
Everything takes longer than you think, to estimate the time required:-Estimate the time you think it should take, multiply be 2 and change the units to the next higher - thus we allocate 2 days for a 1 hour task.

FIRST ALTERNATIVE ROUGH ORDER OF MAGNITUDE LAW:
Everything take longer than you think, to estimate the time required, take your initial estimate and multiply by pi.

COROLLARY TO ROUGH ORDER OF MAGNITUDE LAW
The length of any program rises with the square of the number of people in the development team.

EXTENSION TO ROUGH ORDER OF MAGNITUDE LAW:
What could once be achieved in 3 months by one programmer, in assembler, using GOTOs and self-modifying code in 16K using a mag tape, Now takes a team of 20, 3 years, using all the latest structured programming techniques, need 512K and use 10 300Mb disks ... and will be at least 1 year late and not meet objectives.

LAW OF ON-JOB TRAINING
Experience is directly proportional to Computer time wasted.

SCHAFFNER'S LAW
If a computer has more than enough system resources to run the program, the program will expand to exceed the available resources.

HARTWELL'S EXTENSION TO SCHAFFNER'S LAW
Programs expand at a rate just faster than increases in CPU speed and memory.

GLASGOW'S LAWS OF COMPUTING
1) There are no silver bullets.
2) The likelihood of failure of a project increases as the square of the number of unproven techniques/products/people involved.
3) Quality is not free, but it is cheaper than the alternatives.
4) If you can't describe it in writing, you can't build it. If you haven't described it in writing, don't try to build it.
Corollary to Rule (4) If it's so small it doesn't need documentation, then it doesn't do anything worthwhile.
5) We don't build products, we build prototypes.
6) There are no silver bullets.
7) Complexity is usually the result of either lack of knowledge or lack of adequate thought.
8) Any salesperson claiming 90% reduction in development time is 100% lying.
9) Normalise your design fully, but don't expect to implement it that way.
10) There are no silver bullets.
11) A change affecting n modules in your system will be implemented in at most n-1 modules.
12) There is no such thing as a "one-time quick and dirty" program. Build every program as if God and everyone will see it. They will.
13) If you can't take pride in your work, don't bother doing it.
14) Two years after a system is implemented, no one will remember if it went in on time, but everyone will remember if it went in clean.
15) Never ever modify a vendor package.
16) There are no silver bullets.
17) Beware of any system or product, the name of which tries to imply something about the goodness or quality of that product.

LAW OF INVERSE NEED
The first people in the company to get the latest, most powerful computers are senior managers who will use them to create slide presentations while software developers must produce state-of-the-art software products on obsolete 486s.

FIDDLER'S FIRST RULE:
Anything can be made to work if you fiddle with it long enough.

FIDDLER'S SECOND RULE:
If it ain't broke - don't fix it.

FIDDLER'S THIRD RULE:
If it jams, force it.

FIDDLER'S FOURTH RULE:
If it breaks, then it probably needed replacing anyway.

FIDDLER'S FIFTH RULE (FINAGLE'S 10th RULE OF RESEARCH):
Once a job is fouled up, any attempt to improve it only makes things worse.

FINAGLE'S NINTH RULE OF RESEARCH
In any collection of data, the item most obviously correct, beyond all need of checking, is the mistake and

Corollary 1: No-one you ask for help will spot it
Corollary 2: Everyone who stops by with unsought advice will see it immediately.

If you think that you have solved the Systems Design problem, don't worry - you'll get over it.

Multi-platform applications are ones designed to work equally badly on all platforms.

ULTIMATE ERROR MESSAGE: Warning: Mexican Aardvarks in Load Loader Code!

SELECTED ATKINSON'S LAWS OF COMPUTING
Law 1: All computers and all computing are simply a combination of a very, very large number of very, very trivial things.
Law 3: If you need to read a computer manual, you can't. If you can read a computer manual, you don't need to.
Law 4: All disks eventually crash.
Law 7: All disk drives fill up.
Law 8: There is never enough memory.
Law 11: Sooner or later, you will need to move data from any one computer to another.
Law 14: There will be one operating system, one programming language, and one philosophy of system administration only after there is only one language spoken and one religion practiced on the face of the earth.

LAW OF REVELATION:
The hidden flaw always remains hidden.

EXTENDED LAW OF REVELATION:
Nature always sides with the hidden flaw.

LAW OF UNIVERSAL REVELATION:
The universe is laughing behind your back.

The causes of problems are solutions.

GROSSMAN'S MISQUOTE OF H L MENCKEN:
Complex problems have simple, easy to understand wrong answers.

SMITH'S EXTENSION TO GROSSMAN'S MISQUOTE OF H L MENCKEN:
Complex problems have simple, easy to misunderstand answers.

FIRST LAW OF PROBLEM SOLVING:
If the 4 possible problems perceived are circumvented, a 5th problem will promptly develop.

SECOND LAW OF PROBLEM SOLVING:
Every solution breeds new problems.

THIRD LAW OF PROBLEM SOLVING:
When an error is detected and corrected it will be found to have been correct in the first place.

HELLRUNG'S LAW:
If you wait, it will go away

SHAVELSON'S EXTENSION:
... having done its damage.

GRELB'S ADDITION:
If it was bad, it will be back.

SMITH'S ADDENDUM:
... worse. 

UNIVERSAL TRUTHS OF COMPUTING
1a) The Computer is always right; programmers are occasionally right.
1b) Computers are never more intelligent than their programmers.
2) The amount of time needed to debug a program is inversely proportional to the time allotted for debugging.
3) Programs never work the first time unless there is virtually unlimited time to complete the program.
4a) Any programmer can find 90% of his bugs simply by explaining his program to an uninterested observer.
4b) The rarest bugs in any major programming effort will always show up in a demonstration to the customer.
4c) These bugs are intermittent, usually cannot be reproduced and therefore cannot be located.
4d) You will always find the bug in the last place you would look, and the least expected place.
4e) All major bugs in a software project will turn up five minutes before it is due.
5a) The most difficult or nearly impossible programming problems appear obvious or extremely simple to anyone with little or no knowledge of programming.
5b) Those problems most easily solved by a programmer appear to be overwhelmingly complicated and marvellous to the layman.
6) When a program is working perfectly the programmer will not know what the heck is going on.
7) There is more than one way to crash a system.
8) When a computer is most needed it will break down

NAESEWS LAW:
You can make it foolproof, but you can't make it damn-foolproof

THE "ONE BORN EVERY MINUTE" RULE (EXTENSION TO NAESEW'S LAW)
(1) You can make something foolproof, but you can't make something damn-foolproof.
(2) There is also no such thing as foolproof. Out of the hundreds of births per minute some of are bound to do foolish things at an alarming rate.
(3) Nature's response to "Nobody would be so dumb as to ..." is "There is one born every minute".

LYTTON'S OBSERVATIONS ON CUSTOMER REQUIREMENTS:
(1) Ours is a world where people don't know what they want and are willing to go through hell to get it.
(2) If a user wants something badly, the user will get it badly (done).

FIRST LAW OF BAD MANAGEMENT
If what you're doing isn't working, do more of it.

LANSAM'S LAWS:
1. Everything depends.
2. Nothing is always.
3. Everything is sometimes.

SUMMARY OF MURPHY'S LAW:
Blessed be the pessimist for he shall never be disappointed.

MURPHY'S LAW:
If anything can go wrong, it will

SILVERMAN'S PARADOX:
If Murphy's Law can go wrong it will.

EXTENDED MURPHY'S LAW:
If a series of events can Go wrong, they will do so in the worst possible sequence.

GATES' EXTENSION OF MURPHY'S LAW:
Nothing is ever so bad that it can't get worse.

SCNATTERLY'S SUMMING UP OF COROLLARIES:
If anything can't go wrong it will.

EVAN'S LAW:
No matter what goes wrong, there is always somebody who knew it would.

FIFTH COROLLARY:
Left to themselves, things go from bad to worse.

FARNSDICK'S COROLLARY TO THE FIFTH COROLLARY:
After things have gone from bad to worse, the cycle repeats itself

MURPHY'S LAWS AS APPLIED TO CPU SPEED
(1) If any error can occur, it will sooner or later.
(2) The faster computers get, the sooner the error will occur.
(3) It will also occur more often.

No matter how bad the problem is, it could have been worse. In five years' time you'll look back on today's problems as "the good old days".

FARVOUR'S LAW
There is always one more bug.

BRUNK'S LAW
If a listing has a beginning it has an end.

ZEPPLEMIER'S COROLLARY TO BRUNK'S LAW
The last four pages of a critical listing will be lost.

PENNINGTON'S OBSERVATION
The probability that a given program will perform to expectations is inversely proportional to the programmers confidence in his ability to do the job.

DUNSTONE'S PHILOSOPHY
There is more than one way to boot a disk.

DYKSTRA'S OBSERVATION
If debugging is the process of removing bugs, then programming must be the process of putting them in.

GRAINGER'S LAW OF COMPUTING
If there is any possible way for interaction between people and computer equipment to occur, then there will eventually be damage to the computer.

UNIX'S 43RD LAW OF COMPUTING
Anything that can go wr
Segmentation violation -- core dumped

MURPHY'S LAW FOR PARANOIDS:
Once is accident, twice is coincidence, thrice is enemy action.

DESKTOP PUBLISHING RULES:
Semi-Literate Garbage In - Aesthetically Stunning Semi-Literate Garbage Out.

TRESOR'S QUEUING THEORY:
The other queue always moves faster.

LYTHOG'S EXTENSION:
If you swap queues then the one you join immediately goes slower than the one you left.

SMITH'S EXTENSION:
If you change back, the operator will stop the printer.

SYSTEM MANAGERS PRONOUNCEMENT:
I am system and he who dares trifle with system is lost in the wilderness forevermore.

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

RIEDEN'S LAW OF LATENESS
Lateness is defined as an amount of time sufficient for a completely new geo-political world order to evolve and the human species to go though at least two evolutionary iterations.

BULL'S FIRST EXTENSION TO RIEDEN'S LAW OF LATENESS
If a project is embarrassingly late, change its name and hopefully everybody will think it's a new project and not that old one which was miles behind schedule.

BULL'S SECOND EXTENSION TO RIEDEN'S LAW OF LATENESS
If the First Extension doesn't work, change the name of the company and try to get everybody to think you're nothing to do with the first lot.

HARTWELL'S RULES OF SOFTWARE QUALITY
1. Perfectly working software develops inexplicable faults when Quality Assurance are present.
2. The only person who can understand and fix a 15 year old system on a 25 year maintenance contract was dismissed last week for not wearing a tie.
3. A bug which makes it into the final delivered version will be called a "feature".
4. Three versions later, it will not only still be present, it will be documented.
5. Any bug which eludes detection until Version 10 is a survivor and deserves to live.

ZEROTH LAW OF SOFTWARE ENGINEERING
If you don't have to meet quality requirements, you can meet any other objective.

THE THEOREM THEOREM:
If if, then then.

PENULTIMATE RULE OF COMPUTING
That that is, is.

 

First draw the curves, then plot the data.

If you are stupid enough to use an IBM PC, you only have yourself to blame.

Change password and underwear frequently.

 

MISCELLANEOUS RULES & MOTTOS

The most dangerous person in the world is an idealist with a machine gun.

There are no rules of architecture for castles in the air.

What this world needs is a good 50 billion dollar, 100 Megahurt definite-kill plasma weapon.

My interest is in the future because I am going to spend the rest of my life there.

RELATED CLASSIC HUMOR: Software Project Tree & Swing Diagrams (2 Versions)

DRAGONQUEEN'S LAIR
You are visitor number: