Some people mistakenly refer to software defects as bugs. When called bugs, they seem like pesky things that should be swatted or even ignored. This trivializes a critical problem and fosters the wrong attitude. Thus, when an engineer says there are only a few bugs left in a program, the reaction is one of relief. Suppose, however, that we called them time bombs instead of bugs. Would you feel the same sense of relief if a programmer told you that he had thoroughly tested a program and there were only a few time bombs left in it? Just using a different term changes your attitude entirely.
Defects are more like time bombs than bugs. And though not all of them will have explosive impact, some of them could. When programs are widely used and are applied in ways that their designers did not anticipate, seemingly trivial mistakes can have unforeseeable consequences. As widely used software systems are enhanced to meet new needs, latent problems can be exposed and a trivial-seeming defect can truly be destructive.
At this point, those readers who have written several programs will likely shake their heads and feel I am overstating the case. In one sense, I am. The vast majority of trivial defects have trivial consequences. Unfortunately, however, some small percentage of seemingly silly mistakes can cause serious problems. In one example, a simple initialization mistake caused a buffer to overflow. This caused a railroad control system to lose data. Then, when there was a power outage, the system could not be quickly restarted and all the trains on several thousand miles of track had to stop for several hours while the needed data were reentered.
Some percentage of the defects in a program will likely have unpredictable consequences. If we knew in advance which ones these were, then we could just fix them and not worry about the rest. Unfortunately, there is no way to do this and any overlooked defect may potentially have serious consequences. Although it is true that many programs are not used in applications where failure is more than an annoyance, an increasing number are. Thus, while defects may not be an important issue for you now, they soon could be. It is important that you learn to manage defects now so you will be ready when you truly need to produce high-quality programs.
The software engineer who writes a program is best able to find and fix its defects. It is thus important that software engineers take personal responsibility for the quality of the programs they produce. Learning to write defect-free programs is, however, an enormous challenge. It is not something that anyone can do quickly or easily. It takes data, effective technique, and skill. After all, if you don't strive to produce defect-free work, you probably never will.
Was this article helpful?