TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: Peer Reviews From:Loren Castro <lfc -at- SOL -dot- CHINALAKE -dot- NAVY -dot- MIL> Date:Thu, 31 Aug 1995 10:20:18 -0700
I had sent this directly to Kris. Now it seems that there is some general
interest. This description or peer reviews is specifically for software
engineers (that's what we call our programmers--we don't pay much), but the
principles can apply across disciplines. I have seen the process work well on
several projects. I would add that a QA person should attend (maybe as the
moderator).
lfc -at- sol -dot- chinalake -dot- navy -dot- mil
-------------------------------------------
Design walkthroughs verify the design and its response to performance
requirements before initiation of coding. Code walkthroughs verify the code
and its compliance with coding standards and design documentation. Design and
code walkthroughs for each code segment follow the guidelines given here.
Walkthroughs are peer reviews. Managers are discouraged from attending, and
attempts to evaluate the performance of a designer or programmer are
prohibited.
The purpose of walkthroughs is to find errors and potential problems, not to
correct them. Discussions on how an error can best be fixed are avoided.
Walkthroughs are kept relatively short (no more than 90 uninterrupted
minutes). They are performed with three or more persons in attendance--the
responsible software engineer and two or more other software engineers from the
development team. One team member is designated the moderator. Others may
attend if their expertise is needed to explain the design or code.
The responsible software engineer schedules walkthroughs and distributes all
necessary materials to the reviewers not more than two and not less than one
working day in advance.
The reviewers familiarize themselves with the materials before the reviews.
During the reviews, the responsible software engineer narrates, statement by
statement, the logic of the design or the code. The reviewers ask questions to
explore possible errors.
The moderator controls the reviews (i.e., keeps them productive and prevents
lengthy discussions of solutions to errors). The moderator also records all
errors found and ensures that the errors are subsequently corrected.
Reviews with no errors are documented by simple memorandums prepared by the
moderator, signed by the entire review team, and filed in the responsible
software engineer's software development file.
Reviews that find only minor errors are documented as such but not signed off
until the moderator has verified that all errors are corrected.
Reviews that find many errors or errors of large significance are not
documented and require a rescheduling of the walkthrough after corrective
work.