cedric's bazaar

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
This page is a backup of [[http://liw.fi/programming-truths/ | a list]] written in 1995 that I really like.

  * If it compiles, it works.
  * If it compiles, it's correct.
  * If it runs, it doesn't have any bugs.
  * If it doesn't have any immediately obvious bugs, it's perfect.
  * If a bug doesn't show, it doesn't exist.
  * If it seems to work, it works.
  * Doing something right is easy. Avoiding errors only takes a bit of concentration.
  * The shorter the source code, the faster the program.
  * It's obvious how to optimize a program.
  * Prorammers don't make mistakes.
  * Run-time errors don't occur.
  * Users don't make mistakes.
  * I don't make mistakes.
  * Errors of any kind are rare.
  * Error handling can be done in version 2.
  * It's OK to crash on bad input.
  * It's OK to give incorrect output on bad input.
  * Portability isn't useful.
  * All the world's a VAX. Or, these days, an MS-DOS box
  * The length of the feature list is important.
  * Speed is good, features are better.
  * Slowness can be fixed in hardware.
  * The bigger a program is, the better it is.
  * Random changes to a program fix bugs.
  * Testing takes only a short while.
  * Finding bugs is easy. Fixing bugs is trivial.
  * Bug-fixes don't need to be tested.
  * Trivial changes of any kind don't need to be tested.
  * The first approach, idea, or version is always the best.
  * A 1% crash rate is actually pretty darn good.
  * Code is self-evident. Comments aren't needed.
  * Comments are meant for people other than the original author of the code.
  * Undocumented features are fun and useful.
  * It can always be fixed in the next version.
  * Surprised users are happy users.
  * Demonstrating for clients is the best debugging method.