The Laws of Computing

Recovered from a backup, no less.

Many, many years ago, I collected a set of “laws” associated with computing. Some, like “Adding manpower to a late project makes it later”, are probably familiar, but a few are less well known and just as insightful.

I lost them. Or, rather, I couldn’t find them. I didn’t remember what the file name was, or even what format I had used. I just knew that for many years I carried them with me somewhere.

So, the other day I decided to get serious and started poking around in backup CD images (now copied to hard drives), dating back to 1992. (Man, does that make me feel old.) And sure enough, there it was: LAWS.DOC, on a CD from 1995, including several copies, the most recent being 2002. Old enough that Word would not open the format by default — I had to turn off a security setting to read the file.

So, for your amusement…

Laws of Computing

Gilb’s Third Law of Unreliability

Undetectable errors are infinite in variety, in contrast to detectable errors, which by definition are limited.

Troutman’s Second Programming Postulate

Profanity is the one language all programmers know best.

Brook’s Law

Adding manpower to a late software project makes it later.

Golub’s First Law of Computerdom

A carelessly planned project takes three times longer to complete than expected; a carefully planned project takes only twice as long.

Wyszkowski’s Second Law

Anything can be made to work if you fiddle with it long enough.

The Principle of Multifunctional Devices

The fewer functions any device is required to perform, the more perfectly it can perform those functions.

Brooke’s Law

Whenever a system becomes completely defined, some fool discovers something which either abolishes the system or expands it beyond recognition.

Second Law of Procrastination

Procrastination reduces anxiety by reducing the expected quality of the project from the best of all possible efforts to the best that can be expected given the limited time.

Fourth Law of Procrastination

Procrastination may eliminate the job entirely if the need passes before the job can be done.

Brien’s First Law

At some time in the life cycle of virtually every organization, its ability to succeed in spite of itself runs out.

Eighth Law for Naive Engineers

Major changes in construction will always be requested after fabrication is nearly completed.

Principle of Design Inertia

Any change looks terrible at first.

Eng’s Principle

The easier it is to do, the harder it is to change.

Wright’s First Law of Quality

Quality is inversely proportional to the time left for completion of the project.

First Law of Corporate Planning

Anything that can be changed will be changed until there is no time to change anything.

Leo’s Law

The harder it is to find, the easier it is to fix. And vice versa.

Weinberg’s Second Law

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