itmWEB Research

An itmWEB Classic Whitepaper

Putting an Eyeball on It: Principles of Good Walk-Thrus

Focus Area: Project Management for Systems Development

Author: Russ Finney

Year: 2003

William Gladstone once mused that "the heated mind resents the chill touch and relentless scrutiny of logic". This observation seems to apply remarkably well to the situations frequently faced by technical code reviewers. Why make this chore painful, when it can actually be fun, and beneficial to the team! Using formal code "walk-thrus", especially when multiple team members are encouraged to participate, can have an incredibly positive effect on the system construction process. Some of the advantages of performing these peer level code walk-thrus are:

  • Helps to identify "hidden" logic problems before testing even begins.
  • Verifies that all of the business requirements have been successfully built into the program.
  • Creates a learning atmosphere for entry level programmers to discuss "best practices" with more experienced coders and reviewers.
  • Promotes consistent programming approaches throughout the system.
  • Increases the level of program completeness and quality which put into program, simply because the programmer's peers will be involved in the review.
  • Allows less experienced programmers to share fresh new ideas and approaches with the more senior team members (upward learning!).
  • Creates another opportunity to spot module and class sharing opportunities.

One of the critical activities which should be undertaken before the first walk-thru is conducted is to determine the high-level objectives of the entire process. Answers should be formulated to the following question: Why are we doing this and what do we expect to get out of this process? The team must establish the quality checkpoints that will be at the heart of the code walk-thru reviews. Listed below are a representative sample of some of these quality objectives:

  • Each program follows all established company coding standards.
  • Each program follows all unique project coding standards.
  • Each program follows any common system "coding patterns" which may not be a part of the formal company or project standards.
  • Each program accomplishes its intended business purpose in as straight forward and comprehensible a fashion as possible.
  • All module or class sharing opportunities are utilized to the maximum advantage.
  • No logic errors exist within any of the reviewed programs.
  • All program branches are tied to business requirements.
  • Each program is structured and modularized appropriately.

Once the walk-thru objectives have been put into place, and freshly compiled programs produced, the fun part begins! Pulling a group together to review the code! But who should be involved in the program "walk-thru"? And how many reviewers is the optimum number to be involved in the session? These questions have been the subjects of books, papers, and studies for years. Three to four people seems to be the optimum number and the following roles should be filled:


Since the programmer actually wrote the code (or action diagrams), clearly he or she should be involved in the walk-thru. During this review, the programmer is responsible for stepping the group through the logic within the program, stopping every now and then to highlight a particularly complex or unclear set of statements. He or she should be seeking feedback from the other participants which verifies that all established quality checkpoints are being met and that any improvement opportunities are not overlooked.

Specification Analyst

If the programmer was not involved into the creation of the specifications he or she is coding from, the responsible specification analyst should also participate in the review session. His or her role should be to ensure that all of the specifications have been successfully transformed into code which is both efficient and structured, as well as being an accurate translation.

Technical Specialist

Depending on the overall experience of the programmer and the amount of time he or she has spent on the development application at hand, it may be helpful to have someone sit in the walk-thru who is very familiar with the languages, as well as the coding approaches, being utilized by the team. His or her role is to act as a technical consultant, answering any questions or advising based on experience, as various programming solutions are discussed. In addition, if specialized technical coding is required, the technical specialist is present to assist in this effort and to ensure the correct approach is being taken.

Programming Team Leader

The role of the team leader in this walk-thru is about the same as it was in the design walk-thrus. Making decisions, ensuring consistency, pointing out module or class sharing opportunities, and keeping the session focused are all familiar responsibilities. Again, the team leader should keep the spirit of the review a quest for quality rather than a critique of the programmer's thinking. If the programmer is somewhat inexperienced, the team leader should strive to keep the review non-threatening and educational. This is a chance for the new programmer to benefit from the experiences of others.