Laws of Software Development

Newton watching an apple fall from a tree

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)

Letts' Law

All programs evolve until they can send email. (Richard Letts).

C.f. Zawinski's Law.

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)

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.

Copyright © 2008 Nat Pryce. Posted 2008-11-06. Share it.