Check Marks

In Melinda Varian's VM and the VM Community, Dave Tuttle tells the story of the programming methods of John Seymour, one of the early programmers on IBM's CP/67 (the ancestor of VM/370). In those days, about 1970, paper listings of each module of the system were kept in special racks in the computer room. When John worked on a module, he made a ball-point check mark next to every line of code on the listing as part of his final inspection... except difficult or critical areas of the code, which got two check marks on each line. John's measured performance, back in the early 70s, was 1.1 to 1.2 defects per 1000 lines of BAL code, in the critical and complex routines at the center of the CP kernel, such as the CP memory allocator, DMKFRE. This rate was astounding then, and is still pretty good.

Of course things have changed since Seymour's time. No listings: no place to write the check mark. C++ instead of assembly: more errors caught at compile time, bigger programs. No measurement of per-programmer defects per KLOC.

I think the practice of a final check of every line by the programmer, just before release, is still a good one. It's sort of the first step toward Fagan-style inspections; each checkmark generalizes into a whole vector of answers to checklist questions, for each line.

The key point is that John took responsibility for the quality of his code, and did something about it, and it worked.

(Someday, I'd like to have a system in which a lot of information was associated with each source line, in hyperspace somehow, and a smart editor that would update that information as the source was edited. If I change a comment, nothing happens, but if I change a times operator to a divide, the "could this statment cause a zerodivide?" question would be marked for inspection. I'm not thinking of mechanical theorem proving here: I expect people will have to answer the questions, but I'm imagining systematic bookkeeping so we can know when all the questions have been considered, and remember the answers.)

[Take a look at Kent Beck's Extreme Programming site; similar ideas.]