User Tools

Site Tools


important-programming-truths

This page is a backup of 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.
important-programming-truths.txt · Last modified: 2010/12/22 14:58 by cedric