21 Laws of Computer Programming

Any given program, once deployed, is already obsolete.

It is easier to change the specification to fit the program than vice versa.

If a program is useful, it will have to be changed.

If a program is useless, it will have to be documented.

Only ten percent of the code in any given program will ever execute.

Software expands to consume all available resources.

Any non-trivial program contains at least one error.

The probability of a flawless demo is inversely proportional to the number of people watching, raised to the power of the amount of money involved.

Not until a program has been in production for at least six months will its most harmful error be discovered.

Undetectable errors are infinite in variety, in contrast to detectable errors, which by definition are limited.

The effort required to correct an error increases exponentially with time.

Program complexity grows until it exceeds the capabilities of the programmer who must maintain it.

Any code of your own that you haven’t looked at in months might as well have been written by someone else.

Inside every small program is a large program struggling to get out.

The sooner you start coding a program, the longer it will take.

A carelessly planned project takes three times longer to complete than expected; a carefully planned project takes only twice as long.

Adding programmers to a late project makes it later.

A program is never less than 90% complete, and never more than 95% complete.

If you automate a mess, you get an automated mess.

Build a program that even a fool can use, and only a fool will want to use it.

Users truly don’t know what they want in a program until they use it.