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. Identifying standards: Identifying and conforming to a common set of standards help the peer review practice move from a subjective review to a more objective one. As an example, if coding standards are defined for a code review practice, then the standards can form the basis for the evaluation of code modules under review. Otherwise the code review can turn into a "my method for coding is better than yours" fight. An effective way of keeping an eye on the standards is to create a defect checklist that includes the standards (coding standards, style standards, etc). Also ensure coding standards training is provided. Implementing coding standards helps objectify the code review leading to reduced defects in the current release. It also makes it easier to debug defects found downstream when common standards are applied.

Documented requirements and defects: Along with standards, it is important to have the requirements or defects available that form the basis on why a particular code artifact is being created, changed, or fixed. Having this information can help your peers evaluate the change you are making in relation to the reason for the change. Again, this helps both provide background on the item under review and further objectify the peer review.

Pair programming: Implementing pair programming is analogous to always having someone who is looking over your shoulder and looking out for your best interests. The approach to paired programming is when two developers work side-by-side taking turns on the same artifact or deliverable, one working on the code (and other items like design elements) at a single computer, while the second is constantly reviewing the other's work (e.g., like a continuous peer review). The first place to start is to define and document the pair programming practice you plan to use and share this information with the paired teams so they understand how to work together. To ensure you are building a pair programming practice for success and have more perceived value, consider the following:

Finding peers: Similar to a peer review, when you are implementing a pair programming approach, it is important to ensure that two programmers are peers of one another. But unlike peer review, the 2 programmers really should be professional equivalents (e.g., roughly at the same level of experience). Pairing folks that are at different levels can be intimidating to the more junior person unless the senior person is a nurturer. Pair programming should not be used as a training program to bring more junior level folks up to speed. The senior member may become unhappy and it may be an ineffective use of their time. While the levels of experience should be similar, the areas of expertise can vary (e.g., one can be more skilled in data engineering while the other is more experienced in workflow). Therefore, consider who the peers really are (e.g. those at or near the same professional level of experience) and pair them appropriately.

Working as a pair: Many programmers simply work better in isolation. They like to review the requirement or defect and individually derive the best programming solution per their skill level. Then they like to code as and when they want to code without restraint of another's schedule or work hours. In pair programming, the two programmers work together constantly and will be assessing each other's deliverables continuously. This means they must work roughly the same hours and agree to the working process. Most importantly the pair must enjoy each other's company, have similar personalities, have flexible egos, and be constantly open minded of each other's ideas and opinions. Otherwise, this working relationship can be frustrating to one of both of the pair.

Focusing on problem-solving work: Pair programming is not for all types of programming work. For example, it may be an ineffective use for maintenance or routine enhancement work. For this type of work, applying a peer review (e.g., code review) at regular intervals may be more efficient. When initiating a pair programming program, identify the better types of work that can make pair programming a success like "release 1" of a product that requires considerable problem solving (in design and coding), or projects that have challenging defects to resolve, or work that requires getting into the flow or zone while also requiring documentation (one member of the pair can keep in the zone while the other does the documentation). Summary
Introducing a peer review or pair programming practice into an organization (or project) can be an effective way to improve quality while minimizing culture change. Peer reviews in the form of a code review can be effective way of identifying defects and therefore improving application quality. When establishing a peer review practice, the following can help to ensure success: establishing coding standards; identifying appropriate level of peers; establishing a closed loop defect system to ensure corrective action; and providing requirements and/or defect records to understand why a particular code artifact is being created, changed, or fixed. Pair programming can also be an effective way of identifying defects and in solving problems, thereby improving application quality. When establishing a pair programming practice, the following can help ensure success: identifying appropriate level of peers; finding people that work well together; and focusing on problem solving work. Once you have started either (or both) practices, continually monitor its effectiveness with both metrics and feedback from the people involved for continuous improvement.

References

1. Peer Reviews in Software: A Practical Guide, by Karl E Wiegers, Addison-Wesley, 2002

2. Strengthening the Case for Pair Programming, by Laurie Williams, Robert R Kessler, Ward Cunningham, Ron Jeffries, IEEE Software July/August 2000 (http://collaboration.csc.ncsu.edu/laurie/Papers/ieeeSoftware.PDF)