Faults found during the walkthrough are not fixed, only found . For the course, students should avoid trying to figure out what the fix is after identifying a fault. This saves time since the walkthrough must be completed during class and also, a single debugger will work more efficiently than a committee discussion. The walkthrough may be driven by going through the lists, or by going through the code with interruptions as needed when the current location in the code triggers a list item. For the course, time may be a factor.
List driven walkthroughs are faster, but less thorough.
Walkthrough results are not used for personnel evaluations, to avoid motivating any participants to be defensive or hold back on noting problems. For the course, this simply implies that the walkthrough itself not count for a grade, at least not beyond simple participation or not. An overview of the code precedes the individuals reviews, which precedes the main inspection meeting. This suggests two meetings, one for an author to overview the code for the inspection team, and another for the actual inspection. A checklist of possible faults to look out for is provided, and the inspection session is driven by methodically going through the code.