Pulier's rule of reuse:
A programmer will look at another programmer's output, no matter how brilliant and declare it garbage
The best law's and rules are named by others who admire the author's work, but this one seemed pretty worthy to me. This got me reminiscing about some laws of software development that perhaps had the same rigour as Newton's Laws, Boyle's Law or Hooke's Law.
The rules I have admired during my career are:
Brooks's Law:
adding manpower to a late software project makes it later
Hofstadter's Law:
It always takes longer than you expect, even when you take Hofstadter's Law into account.
Codd's Rules of relational database management systems which I won't quote here because there are 13 of them.
Moore's Law:
The number of transistors that can be inexpensively placed on an integrated circuit is increasing exponentially, doubling approximately every two years.
This has a number of applications outside of transistors such as processing speed, memory and disk capacity.
Clarke's 3rd Law:
Any sufficiently advanced technology is indistinguishable from magic.
The reason I class this as a software development Law is that it points out the futility of trying to explain the technical details of software to Business users. If a technical decision does not have any business impact then it may as well be magic.
I thought I would check what other software development Laws there are on the net. Here is a good sample from some useful sources listed in the Bibliography below:
Amdahl’s Law
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.
Asimov's laws (Yes its SF but one day a software developer might have to follow them):
- A robot may not injure a human being or, through inaction, allow a human being to come to harm.
- A robot must obey orders given to it by human beings, except where such orders would conflict with the First Law.
- A robot must protect its own existence as long as such protection does not conflict with the First or Second Law.
Atwood’s Law:
Any application that can be written in JavaScript, will eventually be written in JavaScript
Bye's First Law of Model Railroading
Anytime you wish to demonstrate something, the number of faults is proportional to the number of viewers.
Clarke's 1st Law:
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 2nd Law:
The only way of discovering the limits of the possible is to venture a little way past them into the impossible.
Clarke's 4th Law (He's not often credited with this one):
For every expert there is an equal and opposite expert.
Any piece of software reflects the organizational structure that produced it.
You cannot apply a technological solution to a sociological problem.
Greenspun's Tenth Rule of Programming (There actually are no rules 1 to 9)
Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp
This can also be worded “Those who do not understand Lisp are doomed to reinvent it.”
Gustafson's Law (also known as Gustafson-Barsis' law)
Any sufficiently large problem can be efficiently parallelized
Kerckhoffs' law on secure cryptography
A cryptosystem should be secure even if everything about the system, except the key, is public knowledge
Lehmann's Laws
- Systems that are used must change or automatically become less useful
- Through changes the structure of a system becomes ever more complex and more resources are needed to simplify it
Linus's law — named for Linus Torvalds,
given enough eyeballs, all bugs are shallow
Lubarsky's law of Cybernetic Entomology:
There is always one more bug.
McLuhan's Law:
If it works it's obsolete.
In communications and network theory, states that the value of a system grows as approximately the square of the number of users of the system.
Murphy's Law
If anything can go wrong, it will.
Occam's Razor:
There are many wordings for Occam's razor and debate about how it is interpreted but from software development I think the best wording is "The simplest solution is usually the best". This is very nearly the same as the KISS principal "Keep it simple stupid".
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.
Sturgeon's Revelation (sometimes referred to as his second law):
Ninety percent of everything is crap
Weinberg’s Law:
If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization.
Software gets slower faster than hardware gets faster.
Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.
Here are still more great laws from Joey DeVilla's Blog posting.
| The Law | Who Said It | What it Says |
|---|---|---|
| Ellison’s Law of Cryptography and Usability | Carl Ellison | The user base for strong cryptography declines by half with every additional keystroke or mouse click 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. |
| 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. |
| 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 (restated) | Jim Gray | Most production software bugs are soft: they go away when you look at them. |
| Hoare’s Law of Large Programs | C. A. R. Hoare | Inside every large problem is a small problem struggling to get out. |
| 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.” |
| Lister’s Law | Timothy Lister | People under time pressure don’t think faster. |
| 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. |
| 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. |
| Reed’s Law | David P. Reed | The utility of large networks, particularly social networks, scales exponentially with the size of the network. |
| 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. |
Some unattributed "laws" that are worth mentioning:
- Build a system that even a fool can use, and only a fool would want to use it.
- Any program over 100 instructions can be simplified by 3 instructions (without losing any functionality).
- Any idiot can learn to use computers, and many do
- 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.
This posting started with Pulier's Law: "A programmer will look at another programmer's output, no matter how brilliant and declare it garbage". At the risk of repeating Pulier's conceit of naming law about himself I propose:
Kimber's Corollary:
No amount of documentation is ever sufficient to completely understand a system
Bibliography
http://en.wikipedia.org/wiki/Adages_named_after_people
"Moore's Law is Dead", http://www.techworld.com/opsys/news/index.cfm?newsid=3477
http://en.wikipedia.org/wiki/Change_management_(engineering), This includes the reference to Lehmann's Laws siting Hinley, D.S. (1996). Software evolution management: a process-oriented perspective. Information and Software Technology, 38, 723-730
http://en.wikipedia.org/wiki/Moore
http://en.wikipedia.org/wiki/Occam
http://www.webopedia.com/TERM/C/Codds_Rules.html
Joey de Villa, http://globalnerdy.com/2007/07/18/laws-of-software-development/
Phil Haack, 19 Eponymous Laws Of Software Development, http://haacked.com/archive/2007/07/17/the-eponymous-laws-of-software-development.aspx
Eric Pulier and Hugh Taylor, "Understanding Enterprise SOA", Manning Publications, 2006
No comments:
Post a Comment