This is a 1978 book, but despite a few anachronisms (24-hour turn-around time for compilations, keyboarding done by someone other than the programmer, etc), the book is as up-to-date as ever. YOURDON Inc published it.
Distinguish between formal walk-throughs, where the boss is present (and maybe a few people from QA and a customer rep) and informal walk-throughs, in which a collection of one's peers goes over the work. Formal reviews can have their place, but they force the presenter to spend extra time prettying up his presentation, and create an atmosphere in which one is less likely to try to find bugs. Informal reviews, or better--peer reviews, are more likely to be productive (plausible).
Yourdon doesn't like the idea of walkthroughs delayed until the program has started testing, much less until after testing, since there is by then too much programmer ego involved. In addition, it wastes some time the programmer spends debugging, when bugs could be caught by the team more quickly. He also notes that a well tested program has few bugs to be caught; and when walkthrough teams are fed a diet of programs with few bugs, they come to expect few bugs, and become sloppy. He suggests walkthroughs at specification and design time (very true) , and before the programmer starts testing (That I'm not so sure about. With us the programmer is the first user, and presumably has some physics tests in mind already. Perhaps his tests aren't as thorough as they could be, but that will come with practice.).
In a walkthrough people have several roles to play. The first is, of course, the
Our proposal abbreviates this considerably. We propose, for the time being, one-on-one walkthroughs. The User Rep is redundant, except for packages we have written by professional programmers. The Coordinator is also the QA inspector and the Standards Bearer and even the Secretary, all rolled into one.
Before the walkthrough, the Presenter gets listings, specs, docs, diagrams, etc and notifies the Coordinator. The Coordinator schedules the meeting and make sure everyone participating has all materials and actually shows up . The rest commit the time required, which is generally about an hour to prepare for a 1/2 hour review. He suggests that each particpant bring one positive and one negative comment, to make sure they actually read the material.
During the walkthrough, two rules are paramount:
The length of the presentation varies: if this is the 2nd walkthrough, it should go over the old comments first. The purpose of the walkthough is error detection, not error correction! The producer must try not to argue or defend against or challenge comments--it wastes time and gets egos flaring. The reviewers pass out lists of errors that don't need explanation (spelling errors in the documentation, etc), to save time. After everyone has said his piece, the participants vote to `accept it' or `accept it but go fix these things' or `go fix these things and come back for another walkthrough'.
Keep walkthroughs short--it is hard work. Don't schedule more than 2 consecutive walkthroughs--people will fall asleep. Don't walk through code fragments.
Use standards to avoid disagreements over style. The coordinator has to maintain decorum--which can be a problem with some groups.
After the walkthrough the coordinator generates a management summary (without details about bugs!), and detailed comments from the secretary's notes (why not the secretary?), and notifies the appropriate parties. The Producer must understand the comments; fix what's reasonable and be prepared to explain why he didn't `fix' the other things.
Our proposal simplifies this part also. with one-on-one reviews, scheduling is much simpler. The management summary is simply a notice to the librarian to install (or not) the pieces of the software.
Yourdon then reviews The Games People Play (Eric Berne) and applies this to programmers and walkthroughs, mentioning such role games as "Gotcha!", "Martyr", "Yes-But", etc.
He devotes a chapter to how to convince management, pointing out that is 10x less expensive to fix design errors in the design phase than after the code is written. There is a psychological barrier to trying to break one's own code, and the tests you design are likely to overlook the same special cases that your code did. There are intangible benefits to having a team look over code: Better quality code, better training of other programmers (who get to see different ways of solving problems), and insurance (other people have seen the code and could take over if the author is hit by a train).
He then describes when walkthroughs aren't necessary. This is in too-small shops, when the code is very short (our's isn't), and so on.
What can go wrong? Goofing off, Rubber stamping, Trivial arguments, Personality clashes, etc. The participants need some experience in procedures, reminders to skip irrelevancies, and experience at giving and taking critism politely--these help. Mutual respect and a sense of shared responsibility are vital
To begin walkthroughs:
To build teams;
Back to JNB CDF page