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.
Once upon a time, it also included:
Cole’s Law
Thinly sliced cabbage.
It took me a moment to “get” that, but I laughed out loud once I did!
P.S.: Just curious — why did you remove it? It’s hilarious!
A tasty treat, thanks! Mayo or salad dressing?
Hey Leo, I just looked up the derivation of coleslaw. It comes from the Dutch words “kool” meaning “cabbage” and “sla” meaning “salad.” Is it really a nederlands food? 😉
Apparently. I grew up on coleslaw (cabbage salad). My grandmother (from Germany) made it weekly, and it was really vinegary! Or at least I thought so as a child. Now I love it!
I live in Germany and I find some of their salads difficult to eat. Many are either too vinagery or too sweet for my palate.
Literally the first law we learned in Introduction to Engineering was Murphy’s law on the first day of Introduction to Engineering.
Smith’s corollary to Murphy’s Law:
Murphy was an optimist.
Perlis’ Law: Any program with more than 32 lines contains a bug.
Perlis, like Murphy, was an optimist.
Thank you, Mr. Notenboom!
I’m saving a copy as “Notenboom’s Laws of Computing.”
Plus Addenda, to include the comments.
Have a GREAT day, Neighbor!
Thank you! and, thank you for “finding” that which was “lost”!
Gray’s Law of Building Entrances:
If there are two doors to enter a building at the same entrance, the odds are 4:1 that the first door you try will be locked.
Gray was an optimist.
Brook’s Law
Adding manpower to a late software project makes it later.
This, of course, is true, but incomplete, like every other law known to humankind.
Of course, the truth is that any attempt to rescue a project that will come in late, over budget, and below objectives, is actually a New Project, and should be treated as such and set up accordingly. No matter what level of management wants to continue with the old project!
My rule, many years ago was to apply a number of multipliers to the estimates from users, designers, analysts and programmers. From memory they were something like: most projects will be 25% late, will fail to deliver 30% of what they promised, and will be 50% over budget. Ask the user/beneficiary: “if that’s all you get, is it still worth doing?”.
If the answer is a resounding “yes” then do it, otherwise, find a better use of your talents.
I’ll add:
Dad’s Law:
If it’s worth doing, it’s worth doing right!
My addition:
A nearly impossible expectation when applied to software development
My reasoning:
There are more ways to write a function than can be counted, therefore no right way exists
Ernie
The one I’ve probably heard the most was “We don’t have to reinvent the wheel”. But sometimes that would be the right thing if the wheel is old and obsolete.
That sounds more like an update 🙂
Traditional folk wisdom: “If it ain’t broke, don’t fix it”.