[This was also cross-posted to the Tucows Developer Blog]
Inspired by Phil Haack’s article 19 Eponymous Laws of Software Development, I decided to collect laws, axioms and rules pertaining to mainstream software development and put them in a nice, easy-to-read table.
This is by no means a complete list of laws; I’ve purposely stuck to the ones that apply to everyday software development and steered clear of the more theoretical ones. Maybe I’ll compile a more complete list someday.
You’ll notice that some of the laws come from the world of biology — they also appear in some lists of software laws, and I think they still apply.
| The Law | Who Said It | What it Says |
|---|---|---|
| Amdahl’s Law | Gene Amdahl | The speedup gained from running a program on a parallel computer is greatly limited by the fraction of that program that can’t be parallelized. |
| Augustine’s Second Law of Socioscience | Norman Augustine | For every scientific (or engineering) action, there is an equal and opposite social reaction. |
| Brooks’ Law | Fred Brooks | Adding manpower to a late software project makes it later. |
| Clarke’s First Law | Arthur C. Clarke | When a distinguished but elderly scientist states that something is possible he is almost certainly right. When he states that something is impossible, he is very probably wrong. |
| Clarke’s Second Law | Arthur C. Clarke | The only way of discovering the limits of the possible is to venture a little way past them into the impossible. |
| Clarke’s Third Law | Arthur C. Clarke | Any sufficiently advanced technology is indistinguishable from magic. |
| Conway’s Law | Melvin Conway | Any piece of software reflects the organizational structure that produced it. |
| Cope’s Rule | Edward Drinker Cope | There is a general tendency toward size increase in evolution. |
| Dilbert Principle | Scott Adams | The most ineffective workers are systematically moved to the place where they can do the least damage: management. |
| Ellison’s Law of Cryptography and Usability | Carl Ellison | The userbase for strong cryptography declines by half with every additional keystroke or mouseclick required to make it work. |
| Ellison’s Law of Data | Larry Ellison | Once the business data have been centralized and integrated, the value of the database is greater than the sum of the preexisting parts. |
| The Law of False Alerts | George Spafford | As the rate of erroneous alerts increases, operator reliance, or belief, in subsequent warnings decreases. |
| Fisher’s Fundamental Theorem | R. A. Fisher | The more highly adapted an organism becomes, the less adaptable it is to any new change. |
| Fitts’ Law | Paul Fitts | The time to acquire a target is a function of the distance to and the size of the target. |
| Flon’s Axiom | Lawrence Flon | There does not now, nor will there ever, exist a programming language in which it is the least bit hard to write bad programs. |
| Gilder’s Law | George Gilder | Bandwidth grows at least three times faster than computer power. |
| Godwin’s Law | Mike Godwin | As an online discussion grows longer, the probability of a comparison involving Nazis or Hitler approaches one. |
| Grosch’s Law | Herb Grosch | The cost of computing systems increases as the square root of the computational power of the systems. |
| Hartree’s Law | Douglas Hartree | Whatever the state of a project, the time a project-leader will estimate for completion is constant. |
| Heisenbug Uncertainty Principle | Jim Gray | Most production software bugs are soft: they go away when you look at them. |
| Hick’s Law | William Edmund Hick | The time to make a decision is a function of the possible choices he or she has. |
| Hoare’s Law of Large Programs | C. A. R. Hoare | Inside every large problem is a small problem struggling to get out. |
| Hofstadter’s Law | Douglas Hofstadter | A task always takes longer than you expect, even when you take into account Hofstadter’s Law. |
| Jakob’s Law of the Internet User Experience | Jakob Nielsen | Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know. |
| Joy’s Law | Bill Joy | smart(employees) = log(employees), or “No matter who you are, most of the smartest people work for someone else.” |
| Kerckhoffs’ Principle | Auguste Kerckhoffs | In cryptography, a system should be secure even if everything about the system, except for a small piece of information — the key — is public knowledge. |
| Linus’ Law | Eric S. Raymond, who named it after Linus Torvalds | Given enough eyeballs, all bugs are shallow. |
| Lister’s Law | Timothy Lister | People under time pressure don’t think faster. |
| Metcalfe’s Law | Robert Metcalfe | In network theory, the value of a system grows as approximately the square of the number of users of the system. |
| Moore’s Law | Gordon Moore | The number of transistors on an integrated circuit will double in about 18 months. |
| Murphy’s Law | Captain Edward A. Murphy | 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. |
| Nathan’s First Law | Nathan Myhrvold | Software is a gas; it expands to fill its container. |
| Ninety-ninety Law | Tom Cargill | The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time. |
| Occam’s Razor | William of Occam | The explanation requiring the fewest assumptions is most likely to be correct. |
| Osborn’s Law | Don Osborn | Variables won’t; constants aren’t. |
| Postel’s Law (the second clause of the Robustness Principle) | Jon Postel | Be conservative in what you send, liberal in what you accept. |
| Pareto Principle (a.k.a. “The 80-20 Rule”) | Suggested by Joseph Juran, named after Vilifredo Pareto | For many phenomena, 80% of consequences stem from 20% of the causes. |
| Parkinson’s Law | C. Northcote Parkinson | Work expands so as to fill the time available for its completion. |
| Pesticide Paradox | Bruce Beizer | Every method you use to prevent or find bugs leaves a residue of subtler bugs against which those methods are ineffectual. |
| The Peter Principle | Laurence J. Peter | In a hierarchy, every employee tends to rise to his level of incompetence. |
| Reed’s Law | David P. Reed | The utility of large networks, particularly social networks, scales exponentially with the size of the network. |
| Rock’s Law | Arthur Rock | The cost of a semiconductor chip fabrication plant doubles every four years. |
| Sixty-sixty Rule | Robert Glass | Sixty percent of software’s dollar is spent on maintenance, and sixty percent of that maintenance is enhancement. |
| Spector’s Law | Lincoln Spector | The time it takes your favorite application to complete a given task doubles with each new revision. |
| Spafford’s Adoption Rule | George Spafford | For just about any technology, be it an operating system, application or network, when a sufficient level of adoption is reached, that technology then becomes a threat vector. |
| Sturgeon’s Revelation | Theodore Sturgeon | Ninety percent of everything is crud. |
| Tesler’s Law of Conservation as Complexity | Larry Tesler | You cannot reduce the complexity of a given task beyond a certain point. Once you’ve reached that point, you can only shift the burden around. |
| Weibull’s Power Law | Waloddi Weibull | The logarithm of failure rates increases linearly with the logarithm of age. |
| Wirth’s Law | Niklaus Wirth | Software gets slower faster than hardware gets faster. |
| Zawinski’s Law | Jamie Zawinski | Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can. |
Comments (92)
Walch’s law of Blogging and Podcasting:
E=I^2 - Ego equals Influence squared
QrazyQat’s First Law: People referring to Occam’s Razor will usually say it completely wrong, just like you did.
Greenspun’s Tenth Rule seems appropriate here as well: “Every sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.”
In case any of you were wondering, the laws in this list that caught my interest the most were two that I hadn’t heard before:
Spafford’s Adoption Rule For just about any technology, be it an operating system, application or network, when a sufficient level of adoption is reached, that technology then becomes a threat vector.
Dr. Robert Lob’s Law:
Whatever message you are trying to convey, the listener will only hear what is relevant to their current thought process.
also known as Bob Lob Law
amdahl’s law is not only about parallel processing. it is a general statement about performance enhancement. also, unlike many of these laws, amdahl’s is a quantitative law with an equation and everything.
also, where is greenspun’s 10th rule of programming? “Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.”
I like Flon’s Axiom - very good to keep in mind before making generalizations about a programming language.
One of the most obvious ones is missing:
One thing is one thing, the other thing is completely another thing.
Love it! Esp. Joy’s Law!
~Mad Cow
Vierck’s Law: The half life of any developed software product, library, or tool is approximately 18 months.
http://www.mispedia.org/Vierck’s_law.html
Two more laws from the days of yore:
1) Build a system that even a fool can use, and only a fool would want to use it.
2) Any program over 100 instructions can be simplified by 3 instructions (without losing any functionality).
-RDH
You forgot Niven’s laws:
#1 Never throw shit at an armed man
#2 Never stand next to someone throwing shit at an armed man
Larry Niven; great SF writer.
…Mike
Conway’s Law resonates with me. I’ve spent too much time working with a POS system that was 20 years out of date when it was first coded. I have recently discovered that it was coded to look just like the system that it was supposed to replace. Now, I know what your thinking, and this is an awful way to create software. But, I work in financial services so predictable results with minimal risk (read: standard deviation) over decades is actually a very good way for my company to operate.
wagen’s law: the desire to coin new laws exceeds the number of useful laws.
I once saw a “law” attributed to a system engineer regarding Windows Live Search and Microsoft’s attempting to build a system to rival google.
It went something like…
“You build a large system from small *working* systems, not from scratch.”
Later, I tried to find the source but couldn’t. Anyone recall hearing that before? If so, who was the source?
From Edge.org, Hurst’s Law: Any unbounded bitstream tends to irrelevance.…
Check the quote again on Hoare’s Law. It’s “program”, not “problem”.
O’Toole’s Commentary on Murphy’s Law
Murphy was an optimist.
@QrazyQat: In the chart, if a breezier paraphrasing the law exists, I used that instead. Hence, wherever possible, I linked the name of each law to a page that had a more technically correct description (including formulae, where applicable).
For the curious, Occam’s Razor is typically phrased in Latin as entia non sunt multiplicanda praeter necessitatem, which translated, means “Entities should not be multiplied beyond necessity”.
The same germ of thought that gave rise to Occam’s Razor also gave rise to Antoine de Saint-Exupery’s line:
@TJ: Some sources on the ‘net say “Program”, others say “Problem”. Although there is a fine distinction between a problem and a program in computer science (technically, a program is a solution), since Hoare is an academic, I thought that he’d be more likely to use the term “problem”.
I going to need to do more digging around to see which version of the quote is the correct one.
Scape’s Law:
What ever it is that hits the fan will not be distributed evenly.
B. Gehm’s corollary to Clarke’s Third Law.
“Any technology which is distinguishable from magic is insufficiently advanced.”
I always see the “ninety-ninety” law written this way, and it makes no sense:
“The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.”
It should be:
“The first 90% of the code accounts for the first 10% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.”
Or am I missing something?
Cole’s Law:
Thinly sliced cabbage
worth adding - Schneier’s Law (Bruce Schneier):
“Any person can invent a security system so clever that she or he can’t think of how to break it.”
http://en.wikipedia.org/wiki/Schneier’s_Law
Murphy’s Lemma
Any disaster against which reasonable precautions have been taken will not happen. Eg. the mere presence of a fire extinguisher will prevent fires from starting.
The 9th law of unemployment
The less stimulating your life is the more interesting baseball becomes.
Really enjoyed the list - I don’t work in software or computers - but many of these are very true in the real world of manufacturing.
1) Since solutions could be said to be the dual of problems, an imaginative Haskeller may call programs “co-problems”.
2) I have a law of my own. It’s Bitwize’s Corollary to Greenspun’s Tenth Rule: “Any sufficiently complicated Common Lisp or Scheme program will eventually be rewritten in C++, Java, or Python.”
I prefer to translate Ockham’s Razor as “Do not unnecessarily multiply dependencies”.
This is not only a legitimate translation in context, which conveys the same meaning as yours, it also has direct application to system programming as well as general problem solving.
Your code is more reliable if you don’t insist on calling every known module on CPAN, and you don’t use callouts to /usr/bin and /sbin because you’re too lazy to bother figuring out how to write six extra lines of native code instead.
Back in my misspent and paranoiac youth, I coined a theory that goes:
Walter’s Theory Of Police:
If you are traveling by car and see a police patrol car, the odds of you seeing another police car before your trip is over goes up by some tangible amount. If you see a second police car, your odds of seeing a third police car before the end of your trip increase again.
==
I was never brash enough to call it a Law.
What Intel giveth Microsoft taketh away!
@Don: Or am I missing something?
Apparently, a sense of irony. (-:
Don’t forget Nurick’s Law of Creeping Features:
“Just because you can doesn’t mean you should.”
Don McArthur asks:
“Or am I missing something?”
A sense of humor?
http://en.wikipedia.org/wiki/List_of_adages_named_after_people
Publish your sources!
@Don:
Many people don’t catch that bit, but the law is “correct” as originally written. The “mistake” is actually a second gem hiding in the same law. Taking all of the cuteness out of the original phrasing, the law would become something like:
“The first 90% of the code takes 90% of the estimated development time. The last 10% of the code also takes 90% of the estimated development time. As a result, the actual development is nearly twice (180%) of the estimate.”
>“You build a large system from small *working* systems, not from scratch.”
>Later, I tried to find the source but couldn’t. Anyone recall hearing that before? If so, who was the source?
IIRC it was Gall in his excellent little book “Systemantics”.
http://www.amazon.com/Systemantics-Systems-Work-Especially-They/dp/0812906748
Norman’s Standard Estimate
It will take two weeks plus an extra two months for every meeting I have to attend about it.
@Jake: I did not know such a list existed on Wikipedia, so that list was not a source. Hence I didn’t link to it.
I don’t know who came up with this:
The success of a technology depends on how useful it is for money-making or porn.
After all those laws and comments with more laws I think it must be time for only one more.
Fabulous Furry Freak Brothers
Got a lot, smoke a lot. Got a little, smoke it all.
You forgot Furrygoat’s Law:
http://www.furrygoat.com/2005/05/furrygoats_law.html
“Every program attempts to expand until it can read RSS feeds.”
LeMel’s Law of Media Technology Maturity
A media technology is considered mature when it’s name stops being appended to the ends of the titles of content. (e.g., “Jaws 3D”)
Don’t know if he wrote it, but it was in “Computer Lib/Dream Machines” by Ted Nelson:
“Any idiot can learn to use computers, and many do”
Westheimer’s Law: To find out how long a program will actually take, double the estimate given by the programmer and change to the next higher unit. For example, if the estimate is two days, it will take four weeks.
I’m looking for the law that says:
87% of statistics are made up on the spot.
Any clue who’s law that is?
Hanlon’s Law: Never attribute to malice that which is adequately explained by stupidity.
I love this one :
In theory, there is no difference between theory and practice; In practice, there is.
– Chuck Reid
didn’t Harlan Ellison pen a corollary to Sturgeon’s Revelation to the effect of:
“…And 90% of what remains is crap, too.”
(i don’t imagine ellison ever said ‘crud’, and i wish i could find/recall the place where he wrote this… anyone with a better memory than me?)
I think this law is relevant:
Weinberg’s Law: If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization. (Jerry Weinberg)
Viadd:
It’s actually porn, piracy, and playing games
@Alfred,
While we’re on the FFFB’s, don’t forget:
Dope will get you through times of no money better than money will get you through times of no dope.
In addition to having a cool name, Melvin Kranzberg was one of the founding figures of the history of technolgy. His laws apply to most any kind of technology, wired or otherwise.
Kranzberg’s Laws
1st: Technology is neither good nor bad; nor is it neutral.
2nd: Invention is the mother of necessity.
3rd: Technology comes in packages, big and small.
4th: Although technology might be a prime element in many public issues, nontechnical factors take precedent in techology-policy decisions.
5th: All history is relevant, but the history of technology is most relevant
6th: Technology is a very human activity, and so is the history of technology.
Don’t forget Cole’s Law: Thinly sliced cabbage
Europium’s First Law of Indoor Plumbing
The sooner you have to pee, the more distant the restroom.
Europium’s Second Law of Indoor Plumbing
If you can’t hold it any longer, the restroom will be located on the fourth floor, is locked, and requires a key held by the cashier who is presently using the other restroom in the basement.
Stigler’s Law: No scientific discovery is named after its original discoverer.
Discovered by Robert Merton, named by Stephen Stigler.
Putt’s Law: Technology is dominated by two types of people: those who understand what they do not manage, and those who manage what they do not understand.
Wiio’s first law:
Communication usually fails, except by accident.
Others here:
http://www.cs.tut.fi/~jkorpela/wiio.html
Steven
All Trivial Cases are Non-trivial:
“In the Universe, whatever is not specifically forbidden in physics will eventually occur.”
All Software Companies Fail. So if you are ever in one which is worth anything, sell.
http://ohair-sherman.com/Andrew/lundblad.html
Great set. One of my favorite laws of programming is what I call “Strathmann’s Law” or sometimes “Strathmann’s Law of Project Management”:
to whit:
“Nothing is so easy as the job you imagine someone else doing.”
Poor William, blamed for a razor he didn’t invent and that nobody ever seems to get right, while his contribution to the idea of universal rights goes unnoticed.
I guess that’s what you get for being a heretic.
(I’ve always wondered how people ‘translate’ it, when he never wrote it down. It was probably Dun Scotus.)
Now this explains some of the vast number of managers I have had in the 70’s, 80’s and 90’s. Those fools always thought I had it easy when in fact my wife was complaining about how hard I worked.
So, my corollary to this truth of yours is that the person imagining doubtless has little or no empathy for the worker’s efforts.
Where did we get those people from? By the way Fred, think about some of the higher up managers at Smiths.
I hereby declare Strathmann’s Law the winner!
Miles Archer:
I’m pretty sure it’s attributable to a British comedian called Vic Reeves. Although I think he originally stated that “86.6% of all statistics are made up on the spot” which is both more accurate and funnier.
Orth’s First Law of Programming
“Never modify bad code, it just gets worse.”
Corollaries of Orth’s First Law of Programming
“Always start with a clean piece of paper.”
“There is no cure for bad code.”
Orth’s Second Law of Programming
“No matter how simple the task, it will consume more time than estimated if it must be repeated many, many times.”
And finally, I can’t take credit for this one because it predates me by decades if not centuries….
“There’s never time to do it right in the first place, but there’s always time to do it over when it doesn’t work.”
Rule of software development:
Good, Fast, Cheap.
Pick two.
@ Andy B.
Yes! Thanks much. Oh, and BTW, here is the complete quote…
“A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.”
Atwood’s Law: “any application that can be written in JavaScript, will eventually be written in JavaScript”.
Hofstadter’s Law has one ‘ti’ too many…
“Whatever the state of a project, the time a project-leader will estimate for comple_ti_tion is constant.”
(And I’ll bet that’s not the only law he could put his name to.)
@Michael Jones I think you meant Hartree’s Law — I’ve fixed the spelling. Thanks for the heads-up!
Any sufficiently advanced incompetence is indistinguishable from malice.
Rules of Estimations
- A job will always take twice the time you estimate.
- A customer will always want a job done in half the time you estimate.
- This remains true when you substitute ‘money’ for ‘time.’
- They remain in force, even if you double or halve your estimates in attempts to compensate for the effect of these rules.
(ie: Doubling your estimate results in quadrupling the end effect.)
Nice Collection…
Nice way to divert ur mind from - if then else looops
My own personal law of copiers (I used to repair them for a living):
The itch on your nose is directly proportional to the amount of toner on your fingers.
Richards’ Laws of Data Security:
1. Don’t buy a computer.
2. If you must buy a computer, don’t turn it on.
Doesn’t Hofstadter’s law say “even when you don’t take into account Hofstadter’s Law.”?
To whom it may concern: I think Fred Strathmann is an old friend of mine - from grade school. I wonder if you have an e-mail address for him? For myself, I teach philosophy, psychology and mathematics at a few places in singapore so it is hard for me to track people down in the USA. Sincerely, Richard McD
Greenspun’s Tenth Rule seems appropriate here as well: “Every sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.”
I prefer the abbreviated version: “Those who do not understand Lisp are doomed to reinvent it.”
Not specifically programming related, but for security in general (more and more relevant to programming everyday in the Web 2.0 world):
Spafford’s first principle of security administration - “If you have responsibility for security but have no authority to set rules or punish violators, your own role in the organization is to take the blame when something big goes wrong.”
link:
http://www.eweek.com/article2/0,1895,1679514,00.asp
Don’t know who said them:
“Never test for an error you don’t know how to handle.”
“Debuging code is twice as hard as writing it. If you write it to the best of your ability, then you will never be able to debug it.”
“In the chart, if a breezier paraphrasing the law exists, I used that instead. Hence, wherever possible, I linked the name of each law to a page that had a more technically correct description (including formulae, where applicable).”
The link part is good, but the paraphrase you used is simply incorrect. It’s very common for people to use this incorrect description of Occam’s Razor, but that does not make it more correct. Occam’s Razor does not say anything about an idea being correct or even likely to be correct, just that you probably want to go with it until the evidence favors something else.
Richard McDonough:
Are you the person I once knew at Cornell’s grad school, back around 1970?
“If you hear hoofbeats, think horses, not zebras.”
Apparently has a medical origin, but very relevant.
Thanks for that important information about laws it really helpful..Interesting article.
Europium’s Exhortation: “One’s reach should always exceed one’s grasp.”
Europium’s Law of Inevitability: “The manager you work for will always be the one who believes that nine women can produce a baby in one month.”
Europium’s Corollary: “The manager you work for will inevitably be the one who pressured his neurosurgeon into performing the six-hour operation in three.”
Brafford’s Law — Live music is like free software.
Heath’s Law of Authority:
If you detect an authoritarian presence, it’s too late.
Corollary: If you see the traffic cop, don’t bother to slow down
…my law of usability: Make something idiot-proof, and they will make a better idiot.
Trackbacks/Pingbacks (6)
[...] ragmanx The Global Nerdy blog (no, I’d never heard of it before either) has a compilation of named laws of software development. These are comments from relatively well-known (to the geek community, at least) folks that got [...]
[...] Global Nerdy » Blog Archive » Laws of Software Development - "Lister’s Law: People under time pressure don’t _think_ faster." [...]
[...] Laws Of Software Development Ferdy October 21st, 2007 - 11:07 pm Software Development Average time to read 0:20 minutes It’s a bit old, but I discovered these links today. Phil Haack collected together in a post 19 Eponymous Laws Of Software Development, and Joey deVilla, inspired by Phil’s article, collected more laws, axioms and rules pertaining to mainstream software development and put them in a nice, easy-to-read table in Laws of Software Development. [...]
[...] This wouldn’t be an issue except for: The userbase for strong cryptography declines by half with every additional keystroke or mouseclick … [...]
[...] Vanochtend was ik op zoek naar wie een bepaald regeltje nu precies had bedacht en kan vervolgens terecht bij een prachtig overzicht van Software Development Laws op GlobalNerdy.com. [...]
[...] wacky Global Nerdy blog, which not only gave my brain a Friday afternoon stretch, but also featured Laws of Software Development, which is a lot more fun than it [...]