Zero Defect Programming

Out in the field

Once a program is distributed to users, you want the debugging normally turned off, so the program runs fast, and does not clutter the hard disk with trace files. It is important that YOU DO NOT REMOVE THE DEBUGGING STATEMENTS. You also do not want them on a compile-time switch so that they effectively disappear from the run-time executable. There are two reasons:

• the first is that you want the user to turn on the debugging if there is a major problem;
• the second is that, if someone else takes over the maintenance of this program, he/she can easily invoke the debugging and find out what the program is really doing.

Now I can hear the programmers yelling: "The program will run really slowly if it has to bypass all those debugging statements!" They said it in 1968 and they are still saying it in 1998, even though machines now run 10,000 times faster.

The fact is, there are very few places in most programs where speed is absolutely critical; real-time graphic programs, such as 3D action games, are a major exception, but virtually all normal programs could run 5% or even 10% slower and nobody would notice. Leave the debugging in.

Now think about how you want the user to turn it on, if some disastrous error occurs. There could be an obvious "Debugging" line under the "Options" item in the main menu, or perhaps a hidden data value. For example, instead of entering an account number, the user could enter "DEBUG" or "***" which would turn on the debugging feature. The idea is that, if a user calls saying he has found a problem, and you can't figure out what it is, you get him to turn on the debugging, re-run the program, and send you the resulting trace to look at by e-mail or fax