Laws of Software Development
At a recent XTC I mentioned to Ivan, Keith and Steve that I had been collecting Laws of Software Development on my private wiki. They encouraged me to post them up here on my blog, so here they are. Some are well known, others less so, some serious, others humorous or whimsical, but each captures something worth keeping in mind when writing software and/or building systems.
Bram's Law
The easier a piece of software is to write, the worse it's implemented in practice. (Bram Cohen)
Brooks' Law
Oversimplifying outrageously ... adding manpower to a late software project makes it later. (Fred Brooks)
The Cardinal Fundamental Law of Programming
It's harder to read code than to write it. (Anon. Documented by Joel Spolsky)
Conway's Law
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. (Melvin Conway)
Eagleson's Law
Any code of your own that you haven't looked at for six or more months might as well have been written by someone else.
Fitts' Law
The movement time required for tapping operations is a linear function of the log of the ratio of the distance to the target divided by width of the target. (Paul Fitts)
Gall's Law
A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system. (John Gall)
Greenspun's Tenth 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. (Phillip Greenspun)
Hartree's Law
The time from now until the completion of the project tends to become constant. (Douglas Hartree).
Hoare's Law
Inside every large problem is a small problem struggling to get out. (Charles Hoare)
Hofstadter's Law
It always takes longer than you expect, even when you take into account Hofstadter's Law. (Douglas Hofstadter)
Lehman's Law of Continuing Change
A program that is used in a real-world environment must change, or become progressively less useful in that environment. (Manny Lehman)
Lehman's Law of Increasing Complexity
As a program evolves, it becomes more complex, and extra resources are needed to preserve and simplify its structure. (Manny Lehman)
Lubarsky's Law of Cybernetic Entomology
There is always one more bug.
Mosher's Law of Software Engineering
Don't worry if it doesn't work right. If everything did, you'd be out of a job.
The Ninety/Ninety Rule
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. (Tom Cargill of Bell Labs)
Parkinson's Law of Data
Data expands to fill the space available for storage. (Based on Parkinson's Law by Cyril Northcote Parkinson)
Proebsting's Law
Compiler Advances Double Computing Power Every 18 Years (Todd Proebsting)
Spolsky's Law of Leaky Abstractions
All non-trivial abstractions, to some degree, are leaky. (Joel Spolsky)
http://www.joelonsoftware.com/articles/LeakyAbstractions.html
Wirth's Law
Software gets slower faster than hardware gets faster. (Martin Reiser, popularised by Niklaus Wirth)
Yannis' Law
Programmer productivity doubles every 6 years. (Yannis Smaragdakis)
Zawinski's Law of Software Envelopment
Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can. (Jamie Zawinski)
C.f. Letts' Law.