Peer reviews may not seem like a very productive way to spend time, but realizing what they help you avoid brings the real value into perspective.

I don’t think that I appreciated peer reviews until after I paired for a while and then moved to another project where pairing was not being done.  Fortunately, this new project employed a kind of peer review process where each developer had another developer look over their code for problems before it was checked into the source repository.

I had come to rely on my backup.  When that backup was removed, I could tell that something was bound to go wrong.  It was nice to have the review process in absence of pair programming.  It allowed me to have some assurance that I didn’t miss something.

My previous experience with peer reviews wasn't that good.  It seemed to me that the process of meeting together to look at someone else's code after it was written tended to put too much negative pressure on the one who did all the effort.  It also seemed that all too often, the discussion drifted to text formatting instead of missing requirements or poor design.

One of the great things about pair programming is that all code is reviewed at the time of its writing.  It doesn’t require any of these things:

• Sending out invites
• Meeting preparation
• Waiting for someone to have the time to review your work
• Taking notes

Pair programming, on the other hand, gives you the benefit of an informed second opinion at the point at which the code is being written.  It is the cheapest point to fix an error.

Pair programming, when performed as suggested by eXtreme programming, seems to make the peer review process disappear.  It is clear that when people work together to make one product that the intent is to build software not to criticize.  It is easy for a solo developer to try to make a perfect product before a review.  It is likely that no matter how hard the solo developer labors that areas of improvement will be discovered and they probably won't feel better because of it.

   
I believe the reason that pair prgramming makes such a big difference is beacuse it changes the ownership concept.  When pairs work on all code together and switch frequently, the ownership shifts to the team and away from any one individual.  This distributes responsibility for the outcome to the whole and in doing so, makes peer reviews seem to disappear even though they are done over and over again throughout the project.  Some of eXtreme programming's other practices work with pair programming to make the peer review process even better but I better save that for another post.