From Peer Review to Pair Programming


There is always talk about improving application quality.  In many instances, a large quality program gets initiated that either takes a lot of resources and time or introduces change that is too challenging for the organization (or project team) to handle. It is usually better to start on a smaller scale. Focusing on improving application quality in the programming phase, a couple of suggests are: 1) initiate peer reviews (e.g., code reviews) and/or 2) initiate pair programming.  While peer review is more widely known and used in the software development industry, pair programming offers more problem solving possibilities. Both are known to reduce defects and improve quality. The key is to introduce a small initiative like peer review or pair programming ensuring you are building the practice for success.


Peer Review
Implementing a peer review is analogous to adding additional sets of eyes to your work. A peer review provides the owner of the item under review with the added insight of other individuals also wanting a better software deliverable. Peer reviews can help both reduce defects and improve quality. The first place to start is to define and document the peer review practice you plan to use. To ensure you are building a peer review practice for success and have more perceived value, consider the following:

Working in a closed loop: There is a danger that peer reviews get seen as a nice exercise but with no validation that corrections get made. It becomes essential that the peer review has a closed loop process where the important defects identified get reported and tracked through closure. Using the code review as an example, there may be a number of defects found and they should be classified in a way that the critical defects (e.g., those considered severity 1 or 2) can be identified amongst all defects. Those critical defects should then be documented and tracked to ensure that the defects are corrected. This ensures the time spent on the code review has a positive conclusion.

Finding peers: When you think of a peer in your profession, who do you think of? Within the context of a peer review, the peer should be someone who is within two levels of experience above or two levels of experience below. Including folks too junior can make the peer review a waste of time and including folks too senior can be overwhelming and intimidating. Also, including your boss or a person who has perceived position over you can be threatening. Therefore, consider who your peers really are and include them.


About the author

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!