Can you list all the funny laws you can apply to computing ?

Question

We all know the common laws that (seem to) rule computing like Moore's law, etc. But there are the funky ones :

Murphy's law : Something that can go wrong, will.

That's why your if you cover 99 % of your code with unit tests, the 1% breaks during the marketting presentation, the day your mother in law comes for diner while you have a headache. And there is no more toilet paper.

Parkinson Law : A task always take as much time to be performed as you allocate to it.

If you give yourself 3 weeks to code a Class, you will successively think :

• Week 1 : I've got the time...
• Week 2, day 1 : what about trying this design pattern ?
• Week 2, day 2 : This will be easier with the new eclipse plugin. God, my IDE's slow. Let's tweak that !
• week 2, day 3 : This is slow because of my computer. I'll format it. A quick hour and I'll be on (fast) tracks !
• Week 2, day 4 : This is fast, I sould try the new framework. I've got the fire power !
• Week 2, day 5 : Ok this framework sucks. I'll recode that.
• Week 3, day 1 : Hum, What was I doing again ? I'll redesign that, it will help me to dive in.
• ...
• Week 3, day 4 : WTF ?
• Week 3, day 5 : I guess this will do. It has to.

If you give yourself 3 days :

• Day 1 : Ok, let's rock that !
• Day 2 WTF ?
• Day 3 : I guess this will do. It has to.

Fraysse's law : the greater the interest about a subject, the quicker the time goes.

This is why you start checking mails à 8 A.M and stop at 12 (when you are hungry).

And there are Solow's paradox, Peter's principle, Dilbert variation, Pareto's law, Taylor's, Laborit's, Illich's, etc.

Do you know any others ?

Answer 1

My favorite - Sturgeon's Law “Ninety percent of everything is crap”

And the other paradox, that seems contradictory, but results true:

Brooks's law "adding manpower to a late software project makes it later"

Answer 2

Very true Wirth's law of computing:

Software is getting slower more rapidly than hardware becomes faster.

This one quite often turns out to be true as well:

Those that can, do Those that can't, teach And those that can't teach teach teachers.

or alternative (there are far more different variations):

Those who can't do, teach. Those who can't teach, manage. Those who can't manage, consult.

Answer 3

Hofstadter's Law applies to project estimates:

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

Answer 4

A common mistake people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Doulglas Adams.

Answer 5

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

–Brian Kernighan

Answer 6

Zawinski's Law?

"Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems. " -- Jamie Zawinski

(as featured by Jeff.... http://www.codinghorror.com/blog/archives/001016.html)

Answer 7

I don't know who to ascribe it to but I like "62.8% of statistics are made up on the spot". I have found it to be true 72.6% of the time.

Answer 8

The Tao of Programming.

There was once a programmer who was attached to the court of the warlord of Wu. The warlord asked the programmer: "Which is easier to design: an accounting package or an operating system?"

"An operating system," replied the programmer.

The warlord uttered an exclamation of disbelief. "Surely an accounting package is trivial next to the complexity of an operating system," he said.

"Not so," said the programmer, "when designing an accounting package, the programmer operates as a mediator between people having different ideas: how it must operate, how its reports must appear, and how it must conform to the tax laws. By contrast, an operating system is not limited by outside appearances. When designing an operating system, the programmer seeks the simplest harmony between machine and ideas. This is why an operating system is easier to design."

The warlord of Wu nodded and smiled. "That is all good and well, but which is easier to debug?"

The programmer made no reply.

Answer 9

See also 19 Eponymous Laws Of Software Development and Programming Quotations

Measuring programming progress by lines of code is like measuring aircraft building progress by weight.

Bill Gates

(I can remember the progress of the rear fuselage of the Joint Strike Fighter being measured as how close it was to meeting its weight budget, so arguably this is a actually a valid measure)

Answer 10

Zawinski's Law

Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.

Answer 11

Every program has at least one bug. Every program can be reduced by at least one line.

Therefore every program can be reduced to one line...

...And it won't work

Answer 12

The probability of a bug manifesting itself in software quadruples when said said software is being demonstrated.

Answer 13

The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair.

-- Douglas Adams, "Mostly Harmless"

Answer 14

If the car industry behaved like the computer industry over the last 30 years, a Rolls-Royce would cost $5, get 300 miles per gallon, and blow up once a year.

Answer 15

Sometimes I try to be funny with my PC, yet it never laughs back, so I suspect nothing is funny.

Answer 16

Glens Law The time taken to input and then use of any piece of software properly always exceeds the time available