Overview

Many applications we've looked at over the years seemed as though they had just happened. Be it Fortran, Pascal, C, or LabVIEW, it was as if the programmer had no real goals in mind no sense of mission or understanding of the big picture. There was no planning. Gary actually had to use an old data acquisition system that started life as a hardware test program. One of the technicians sat down to test some new I/O interface hardware one day, so he wrote a simple program to collect measurements. Someone saw what was going on and asked him if he could store the data on disk. He hammered away for a few days, and, by golly, it worked. The same scenario was repeated over and over for several years, culminating in a full-featured ... mess. It collected data, but nobody could understand the program, let alone modify or maintain it. By default, this contrivance became a standard data acquisition system for a whole bunch of small labs. It took years to finally replace it, mainly because it was a daunting task. But LabVIEW made it easy. These days, even though we start by writing programs in LabVIEW, the same old scenario keeps repeating itself: Hack something together, then try to fix it up, and document it sometime later.

Haphazard programming need not be the rule. Computer scientists have come up with an arsenal of program design, analysis, and quality management techniques over the years, all based on common...