If you pair program, do you still need a peer review?

Question

I think in general Peer reviews are a very good part of development process, they often catch or question things which were not apparent when code was originally written and make you more self conscious so you format better, put in comments etc.

However if you are pair programming you effectively have a live peer review, so is it worth still having a peer review as part of the process? Can you have pair peer reviews?

I ask as pair programming is starting to happen where I work, and generally this is seen as a substitute for peer review. I am not so sure, but think that the developer time spent pair programming and peer reviewing may damage productivity.

There was a similar question a while back but with different emphasis and no clear consensus

Answer 1

If the partners change in pair programming, then you basically have peer reviews automatically (even more than just one pair of "extra" eyes). And in case both programmers are unsure of how to do something, they can (should) still ask for help, which again results in some kind of peer review.

Answer 2

I think peer review is still important because mind set involved in both cases are quite diffrent at time of programming the normal mind set is not critical while doing peer review the mindset which invloves is of critical analysis its the same like getting the manual testing done by the same devloper who has devloped it would not be as good as getting it done from a tester

Answer 3

That depends.

The goal of a peer review, in my opinion, is not only to find defects directly to the code written but to make sure that the code will also work well with the exist code base. Sometimes, you may want to involve an expert of the code you are writing and it may not be a member of the pair.

For example, if your write the 3D Graphics part of an application, you may want to have it reviewed by your OpenGL expert.

So depending on the circumstances, you may want a third pair of eyes to look at your issue. This person may not even be collocated (in another time zone or something).

Plus, when you pair, you may have a tendency to think alike. Therefore, another opinion may open your eyes on something you missed.

If my developers pair to code, I would still incite them to have their code reviewed if they are not 100% expert in that part of the code.

Answer 4

Pair switching was intended to solve the problem of the peer reviews. When developer joins the new pair, he/she have to understand the problem he/she is going to work on. And the understanding includes the review.

I believe that only separated experts reviews for the crucial points of the system are required.

Answer 5

Paring is the peer review. Or as XP say, if something is good then take it to the extreme. If peer reviews are good, do it continuously i.e., pair programming.

When paired programming is done properly and pairs are rotated frequently, you will accomplish continuous peer reviews of all code developed. Better yet, the code is reviewed as it is designed, tested and written (yes, write the test first A.K.A Test Driven Development) not after the code has been written and more expensive to fix.

Peer reviewed code is but one advantage of pair programming. The other advantages are:

Improved quality: A pair of active programmers working on the same story card will complete the card with less defects

Improved productivity: a pair is less likely to be slowed down if not outright blocked when solving a problem. Furthermore, it is harder to take an email or web vacation when you are working with a partner ... you don't want to let the partner down. You will solve the problem with a cleaner design and less lines of code when working as a pair

Eliminate silos of knowledge: With rotating pairs, you will learn application and domain business knowledge across the team. The team is less likely to be blocked because Sue went on vacation and no one else knows her code.

Skills Transfer: Rotating pairs teach new skills (engineering and domain) to each other as they work together. The level of the team will rise for everyone and the knowledge propagates through the team.

Team self selects: The team learns one anther's skills and will quickly weed out someone that is not performing.