Technical Reviews


Source: Handbook of Walkthroughs, Inspections, and Technical Reviews
by Daniel P. Freedman & Gerald M. Weinberg, 1977


According to the book, the reasons for technical reviews are to

1) Point out needed improvements in a product of a single person or team;

2) Confirm those parts of a product in which improvement is either not desired or not needed;

3) Achieve technical work of more uniform, or at least more predictable, quality than can be achieved without reviews, in order to make technical work more manageable.

There is additional justification related to modern software development methodologies: to

a) Assure that more than one person has seen each part of the projects and has a basic understanding of it (this is also one reason for pair programming);

b) Identify reusable components within a project or across projects (code reuse is one goal of object-oriented programming);

c)Provide data on common mistakes that can then be used in testing (the tests can be added to JUnit or SUnit test suites);

d) Locate areas where code or function is duplicated (the current best practice is to do it once and only once, unless redundancy is specifically called for).


The review can take one of several different forms, such as

††††††† Walkthrough†††††††††††††††††††††††††††††††††††††††††††††††††† Inspection

††††††† Round-robin review††††††††††††††††††††††††††††††††††††††† Informal review


Review materials can include

††††††† Functional specifications††††††††††††††††††††††††††††††† Designs

††††††† Code††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††† Documentation

††††††† Test plans††††††††††††††††††††††††††††††††††††††††††††††††††††† Tools and packages

††††††† Training materials and plans††††††††††††††††††††††††† Procedures and standards

††††††† Operations and maintenance procedures


Participants in the reviews are often

††††††† Review specialists††††††††††††††††††††††††††††††††††††††††† Other team or department members

††††††† Experts in the subject matter being reviewed People interested in the product

††††††† Visitors/volunteers wanting to contribute††††††† Invited people from elsewhere in the organization

††††††† Management††††††††††††††††††††††††††††††††††††††††††††††††† Producer of the reviewed material


At least three roles need to be filled during the review: the roles of

††††††† Recorder††††††††††††††††††††††††††††††††††††††††††††††††††††††† Review leader

††††††† Reviewer

Others might include

††††††† Program writer††††††††††††††††††††††††††††††††††††††††††††††† Reader


The producer and reviewers can use creative tactics.Tactics include

††††††† Playing Devilís advocate††††††††††††††††††††††††††††††† Instituting stand-up reviews

††††††† Bebugging††††††††††††††††††††††††††††††††††††††††††††††††††††† Money bowl

††††††† The alarm†††††††††††††††††††††††††††††††††††††††††††††††††††††† Playing the issues list bloodhound


The review can result in various reports such as

††††††† Summary report†††††††††††††††††††††††††††††††††††††††††††† Issues list

††††††† Related issue report†††††††††††††††††††††††††††††††††††††† System history