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