Topics
Laws of Computer Programming
Computer Programming Quotes
Bug fixing and reparations
Sloppy Inventions
Famous Flops
IT Project Failures
Laws of Computer Programming  
Laws of Computer Programming
Murphy's Laws of Computer Programming


Laws of Computer Programming
As any experienced computer programmer knows, there are unwritten laws that govern software development. However there are no penalties for breaking these laws; rather, there is often a reward.

Following are Murphy's and other Laws of Computer Programming

1. Any given program, once deployed, is already obsolete.
2. It is easier to change the specification to fit the program task than vice versa.
3. If a program is useful, it will have to be changed.
4. If a program is useless, it will have to be documented.
5. Only ten percent of the code in any given program will ever execute.
6. Software expands to consume all available resources.
7. Any non-trivial program contains at least one error.
8. 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.
9. Not until a program has been in production for at least six months will its most harmful error be discovered.
10. Undetectable errors are infinite in variety, in contrast to detectable errors, which by definition are limited.
11. The effort required to correct an error increases exponentially with time.
12. Program complexity grows until it exceeds the capabilities of the programmer who must maintain it.
13. Any code of your own that you haven�t looked at in months might as well have been written by someone else.
14. Inside every small program is a large program struggling to get out.
15. The sooner you start coding a program, the longer it will take.
16. A carelessly planned project takes three times longer to complete than expected; a carefully planned project takes only twice as long.
17. Adding programmers to a late project makes it later.
18. A program is never less than 90% complete, and never more than 95% complete.
19. If you automate a mess, you get an automated mess.
20. Build a program that even a fool can use, and only a fool will want to use it.
21. Users truly don�t know what they want in a program until they use it.

Murphy's Laws of Computer Programming

1.Only ten percent of the code in any given program will ever be executed.
2.If a program is useless, it will have to be documented.
3.If a program is useful, it will have to be changed.
4.Any non-trivial program contains at least one bug.
5.Any program will expand to fill all available memory.
6.The value of a program is directly proportional to the weight of its output.
7.The complexity of a program will grow until it exceeds the capability of the programmer to maintain it.
8.Make it possible for programmers to write in English and you will find that programmers cannot write in English.
9.If builders built buildings the way programmers write programs, the first woodpecker that came along would destroy civilization.
10.Inside every small program is a large program struggling to get out.
11.If a test installation functions perfectly, all subsequent systems will malfunction.
12.Not until a program has been in production for at least six months will its most harmful error be discovered.
13.Undetectable errors are infinite in variety, in contrast to detectable errors, which are by definition limited.
14.If the input editor has been designed to reject all bad input, an ingenious idiot will discover a method to get bad data past it.
15.Build a system that even a fool can use, and only a fool will want to use it.
16.Machines work; people should think.
17.A carelessly planned project takes three times longer to complete than expected; a carefully planned project will take only twice as long.
18.Adding manpower to a late project makes it later.
19.The effort required to correct an error increases geometrically with time.


Here are another Eight Troutman's Laws of Computer Programming
1. Any running program is obsolete.
2. Any planned program costs more and takes longer.
3. Any useful program will have to be changed.
4. Any useless program will have to be documented.
5. The size of a program expands to fill all available memory.
6. The value of a program is inversely proportional to the weight of output
7. The complexity of a program grows until it exceeds the capability of the maintainers.
8. Information necessitating a change in design is always conveyed to the implementers after the code is written. Corollary: Given a simple choice between one obviously right way and one obviously wrong way, it is often wiser to choose the wrong way, so as to expedite subsequent revision.
9. The more innocuous a modification appears, the more code it will require rewriting.
10. If a test installation functions perfectly, all subsequent systems will malfunction.
11. Not until a program has been in production for at least six months will the most harmful error be discovered.
12. Interchangeable modules won't.
13. Any system that relies on computer reliability is unreliable.
14. Any system that relies on human reliability is unreliable.
15. Investment in reliability increases until it exceeds the probable cost of errors, or until someone insists on getting some useful work done.
16. There's always one more bug.