After a small introduction by the manager, the author
explains his source code in a presentation. The program is inspected in
small steps. Any questions during the speech are discussed with the
goal to detect faults . It is impressive how many
bugs are found by the author himself while explaining the program to
others. In other words, a lot of faults are found just by presenting a
product to an audience .
Under all circumstances, the host has to prevent the team from trying to find fixes for the faults found. Those will be fixed by the author later, and he will get the chance to explain his fixes in a later meeting. This will also reduce the chance of new bugs created during the correcting -- and those bugs are pretty likely.
Once again, the host is responsible for a productive atmosphere. This
starts with the choice of the time for the meeting, continues
with the prevention of external distractions, and includes things like
the right moment to end the meeting. Since code-inspection is a
extremely intellectual activity, it should not last longer than two
hours. He should plan several meetings for longer programs, because it
has turned out that in the average about 150 instructions are covered
per hour. Another thing he has to take care of, is the members'
attitude towards each other. For instance, as soon as the
author regards the inspection as a personal attack, the
lack of success is predeterminated. However, if the author keeps a
ego-less attitude, the meeting has a good chance to be
very productive .