Checklist for Code Walkthroughs (Draft, Version 1.2, 10/30/97)

Before the Walkthrough

Collect the package*. This may include:

Requirements (what is this code supposed to do?)
Design Doc (what is the overall shape? how do the piece fit together?)
Protocol Diagrams
Expected Usage (scenarios, programming skeletons, sample programs)
Code (a line numbered version helps the review!)
Reference pointers (if the code uses a special library, coding style, etc., provide pointers to where the participants can find explanations)

Pick the participants. This may include:

the developers
selected additional technical types
(OPTIONAL) additional interested parties (send a public invitation to source-reviewers, saurons, etc. and see who turns up? if so, make it clear that participants are expected to invest up front time and "get with the process")

Pick a time
Arrange for a room
Send out a notice, providing:

Pointer to the package
time and place
Basic agenda
Description of the process that is expected

At the Walkthrough

Go over the rules and the process with all participants before you start.
Identify roles: Who is the facilitator? Who is taking notes?
Collect Issues, Don't Solve Them
Don't defend the code or the project--this is NOT the right place to rearchitect, redesign, or just whine.
Do understand the issue. If it isn't clear, ask for definition, explanation, examples.
Do one issue at a time. Until it has been restated clearly and everyone agrees that the statement accurately captures the issue, do not go on to the next issue.
Drop the egos at the door. An issue with the code is NOT an issue with the person who wrote it--as far as possible, consider this code as having been spontaneously generated by 10,000 random monkeys hammering on keys--your job is to find the Shakespearean phrases in the middle and point out the cruft around the edges.
Do notice good as well as bad. If there is a piece of code that is really clear, well-written, etc. -- say so!

(Note: a list of possible questions to help in a code walkthrough can be found here.

After the Walkthrough

Collect all the issues in written form and send it to participants.
Soon, decide what to do with each issue. If needed, hold a follow-up meeting to assign corrective work or decide what to do with each issue.
Publicize what happened with each issue.
Stow a copy of the package and the results in your project notebook.

* (Note: the "package" may consist of a page pointing to where materials are, or it may actually be a physical collection of the materials, depending on the project. Especially in current development efforts, I would expect most "packages" to be "virtual" ones, consisting of links or reference pointers to the materials.)

Note: a 2,500 line packet of code is just about the right size for a two hour code review.

Note: Have some of the reviewers read the code in a different order. The code you read first and the code you read last are treated somewhat differently.

Note: If you want to have everyone use the same package, hand it out physically before hand AND/OR provide directions for how to do the line numbering.