Cleanroom Software Development

I thought that after 28 years of programming for a living I would eventually stop writing buggy code. Well, yes and no. I make a lot fewer now, but in my recent work there were still a few embarrassments.

Then my good friend and colleague, Dr. Allan Stavely of the Computer Science Department here at New Mexico Tech, got an NSF grant to study a new methodology called Cleanroom Software Development. Since this intensive class, he has twice taught a 3-hour course in the methodology, and I got to take in the spring of 1994.

Although I haven't used this method for anything really huge yet, so far it looks like just the thing to get my bug rate down by the next order of magnitude or two.

Unfortunately, as of yet there are no books on the method. You can take IBM's course, or you can come to New Mexico Tech in the spring of '95 and take CS489.

The name comes from analogy with the cleanrooms of wafer fabrication plants. Rather than trying to clean the crud off wafers after they are made, the object is to prevent the dirt from getting into the fab environment in the first place. Similarly, with the Cleanroom method, the aim is to write the code correctly the first time, rather than trying to find the bugs once they are there.

This method steers a nicely balanced course between the extremes of correctness proofs and no methodology at all. The originators (principally Harlan Mills) claim that the method produces highly robust code without taking any longer than the traditional software lifecycle. The difference is that proportionally much more of the time is spent in design.

Here is an extremely sketchy outline of the methodology:

  1. Each ``primary program refinement'' or ``prime'' (module) is defined mathematically as a function that sets each of a list of variables to some value. These replacements are defined as happening in parallel.
  2. The code for the prime is written. Primes may be terminal (a sequence of code with no procedure calls) or non-terminal (either a sequence of lower-level primes, or one `while' or `if' construct involving lower-level primes).
  3. The code for the prime is verified against the intended function in a peer review meeting. Unless every member of the peer review panel is completely convinced that the code matches the intended function (possibly with trivial changes), the prime is sent back for rework and reverification.
This is a stepwise refinement method, so we start by describing the intended function for the system as a whole, and refine until all the primes are verified, all the way down to the terminal modules.

I think the method will work best with experienced programmers, but even with undergraduates we were able to put together nearly bombproof code for the class project.

See also the September 1994 issue of Scientific American, "Software's Chronic Crisis" by W. Wayt Gibbs, pp. 86--95.
John W. Shipman (john@nmt.edu)