Pair Programming vs. Code Review

My impression of pair programming vs. code reviews has always been that they are two points on a continuum of code feedback, along with code then throw over the wall to QA (eek!), and code then throw over the wall to customers (double eek!).

The main negative of code reviews vs. pairing is the delay in feedback. However, pairing requires more discipline of developers, and puts more constraints on the development environment. Reviews work in scenarios where pairing is discouraged, such as distributed teams or an environment hostile to the idea. In my first job out of college, a second developer was required to review all work, and on the whole, it worked out very well.

So on the whole, I see code reviews as a large step forward in shortening feedback cycles for code, either as a means to introducing pair programming later on, or as an end itself. There are definitely worse things you could be doing.

I like the approach of pair programming to develop the code and using a code review when needing to get more people familiar with the product. In addition the revew can serve as a peer reinforcement of coding standards.

I don't agree that code reviewers aren't personally invested in the code nor will they need to use it. Frequently code one person writes affects another, and everyone knows it. Also no one wants to fix bugs no matter who was the code owner, so it's in everyone's best interest to find bugs.

I like Evan's proposal that pair programming is stronger but takes more time but isn't always possible. Taking it another step forward, in practice it's common for the powers-at-be to disallow pair programming (almost) completely, so whether or not that's wise we need to develop other forms of code review as viable alternatives.

(Lightweight) code review takes much less time. Even if it's less effective, a case can be make for the ROI of code review being better than that for pair programming, especially when deadlines are looming.

Yes, problem undetected now cause more delay later, but sometimes "releasing soon" takes priority.

Thanks for a nice article highlighting a point people discuss frequently.

I think whether pair programming works or not depends on whom you are pairing with.Means if the person you are working with is less knowledgeable or less cooperative pair programming doesnt make much sense.In those scenarios it just become wastage of time as it involves two developers working on the same code.

While reviewer's aren't necessarily less invested, I find that in practice, 80% to 90% of the time they are.

This leads to another interesting contrast. In a code review situation, it is easy to be less invested, while in a pair programming situation it is more difficult to be less invested.

I'm always slightly annoyed when this tends towards a binary, "which is better?" debate. When done well, the two activities work together to achieve largely different goals.

Sure, both have the 2 ultimate goals of a) better resultant code and b) knowledge sharing...but, really, you could say that about many (most? all???) commonly suggested software dev practices.

My take on what "done well" looks like (ideally):
- Pair Programming is used as the primary means to most efficiently arrive at the most effective solution
- Code Review is used as a means to keep the entire team up to speed with what everyone else has been pairing on. Knowledge sharing, really.

Does that mean that changes shouldn't be suggested in a code review? No. But the most painful and de-constructive code reviews I've ever seen were all the result of people focusing too much on nitpicking designs, rather than focusing mostly on learning (and saving the suggestions only for the "biggies").

Does that mean that knowledge isn't shared when pair programming? No, of course not. But, it really isn't intended to be the focus.

So...I guess what I'm saying is: "Both" :-)

FWIW, I've blogged a couple times recently about pairing, you may (or may not!) find relevant:
"Why do pears fall in love?"
"Riddle me this, Mr. Pair Programmer"

ps// I'm sorry, shameless marketing, but I can't help but to also point out my latest entry with my take on "chickens & pigs".

Measure the defect rates using pair programming over enough iterations to be confident that you have a valid sample of the norm.

Now, measure the defect rates using code reviews over the same number of iterations. Be sure you're using the same team on the same project.

Is there a significant difference? Keep on monitoring over time to determine if new bugs tend to trace back to code review iterations or pair programming iterations.

Run McCabe Cyclomatic Complexity metrics on the code generated during these iterations. Are the McCabe numbers significantly higher (more complex code) on average during code review iterations vs. pair programming iterations? Bugs tend to cluster in complex modules.

Now evaluate team velocity over those same iterations. Is velocity significantly higher or lower with code reviews vs. pair programming? How is productivity impacted by either alternative?

Me - I get more joy out of pair programming. Code reviews feel tedious. But that's too subjective. Who's going to be the first to conduct an experiment?

I agree with the need to measure both approaches and apply accordingly but, fwiw, to answer the points in the original post from my experience ...

I have had the chicken/pig problem in code reviews on traditional projects where it felt like the reviewers were more interested in scoring points against each other than producing quality code. However, I have also experienced the complete opposite on FDD projects. Here the reviewers are mostly part of the feature team and as such are intrinsically committed to getting each other's code working well. Also the code of each member of the team is being reviewed, often in turn, so the feeling of being in the hotseat is also shared. The team pass or fail the review together.

These days, the use of static code analysis tools like checkstyle can remove much of the nitty gritty aspects that traditionally bog down a code review.

Teams I have worked with have found pair programming highly effective when working on a particularly sticky problem or a new area. When coding simpler or familiar stuff, they have found it much less effective ... and when the sun is shining through a window into an already warm office after lunch and I am not the one driving the keyboard, zzzzz!

I have found that constant pair-programming is also less necessary with FDD feature teams. The team have worked collaboratively around a white board to agree a low-level design for the features being developed. Therefore, the actual coding up of the design involves fewer decisions.

In addition, while pair-programming gives instant feedback, it loses the benefit of 'fresh eyes'. I find problems often jump out when coming back to a piece of code after a hour or two away from it. Pairs can be too close and not see the wood for the trees.

...but in the end measure it and adapt accordingly.

Do you think such measurements are possible? With professional programmers whose main goal is to get software delivered?

I used to say the design review was too early (nebulous) and code reviews were better.
Then I said that the code review was too late to catch the structural problems with the code, and a design review would be better. Pair programming is closer to the sweet spot when the feedback is most effective.

I personally don't believe in such metrics.
Collecting reliable data would be just impossible. You cannot re-enter the same project state to measure the same things twice (once with code review, once with pair programming). Your team would be more experienced, your code would be older (different, maybe better, maybe worse - but not the same), your requirements will be at least slightly different.

So again: stay agile. People over processes & tools (which include metrics). Common sense rules!

In a recent discussion with some developers who argued against pairing I posed the question if at the end of the week on a project I sit with you and you review 200 lines of code how likely is it that I am going to scrap those 200 lines and redesign/rewrite it? the answer "not likely", so what if it is 100 lines? the answer pretty much the same...ok what about 1 line of code...the answer "yes you are very likely to rewrite/redesign it"

I think most of us already know this but it's worth reiterating that Pair Programming is not about Programming but it's about Programmers (people). You just can't put two random programmers to pair together and expect good design or code or productivity from them. Like any other pattern or practice, pair-programming practice has to be used in the right context (i.e. right place, right time and with right people) to get the best of both programmers. This is true for any practice (Agile/XP/Scrum) where some of the practitioners of these methodologies have forgotten the spirit behind the practices like Pair Programming.

Here is how I manage the design, development, unit testing, and (sometimes) pair-programming in my projects:

Design:
I always run my design ideas by at least one team member to make sure I didn't miss any alternate (and better) design options for the use case I am working on. I do this before I write a single line of code.

Coding:
Once I have the design discussion and coding done, I ask a team member to do a code review before it's promoted to Test environment.

Unit Testing:
I try to follow TDD as much as possible when I write any new code, but when I have to modify existing legacy code that doesn't have any unit tests, I follow the other "TDD" practice (Test During Development :).

Pair Programming:
I do work with other programmers when there is a task that requires a specific domain knowledge that I am not familiar with. This way, I bring the technical experience to the table whereas the other developer brings in the business domain expertise and we both can help each other solve the problem faster than we would have if we had worked on it separately (synergy effect).

Pair-programming has value but I am not a big fan of 24x7 (or 9 to 5) pair-programming. I rather like the option of collaborating and working together on-demand to solve a specific problem.

Pair programming is a powerful technique to not only increase the quality of the overall development from the bottom up, but also improve communication and joint ownership. It can and should be done even in more traditional shops.

In the end, the goal is to ensure multiple developers know and agree with the code. From that respect, I see a continuum ranging from more traditional code reviews to pair programming.

Traditional code reviews are suboptimal, from what I have seen, when the reviews cover too much code at once, are too rare, too formal, are perceived to be "penalty-oriented" or not constructive and reviewers do not have enough involvement, knowledge, interest or do not enjoy the respect of the reviewed. The code reviews cannot be seen as a burdensome formality but as an opportunity for code and personal improvement. I also like the idea of daily or weekly informal and jointly agreed reviews between peers.

In the absence of the possibility for face-to-face interaction, code change notifications (preferably automated) also offer a very good opportunity for timely and valuable feedback.