Pair Programming vs. Code Reviews

Tom Dommett wrote in to share his positive experience with pair programming:

The idea is two developers work on the same machine. Both have keyboard and mouse. At any given time one is driver and the other navigator. The roles switch either every hour, or whenever really. The driver codes, the navigator is reading, checking, spell-checking and sanity testing the code, whilst thinking through problems and where to go next. If the driver hits a problem, there are two people to find a solution, and one of the two usually has a good idea.

Other advantages include the fact that where two people have differing specialities, these skills are transferred. Ad-hoc training occurs as one person shows the other some tricks, nice workarounds, etcetera.

The end result is that both developers are fully aware of the code, how it works, and why it was done that way. Chances are the code is better than one developer working alone, as there was somebody watching. It's less likely to contain bugs and hacks and things that cause maintenance problems later.

In a bigger team, the pairing can change each week so each team member is partnered with somebody different. This is a huge advantage, as it gets developers talking and communicating ideas in the common language of code.

We found this to be as fast as working separately. The code got written quicker and didn't require revisiting. And when it did need to change, more than one person was familiar with the code.

It's an encouraging result. I applaud anything that gets teams to communicate better.

I'm intrigued by the idea of pair programming, but I've never personally lived the pair programming lifestyle. I do, however, enjoy working closely with other developers. Whenever I sit down to work side by side with a fellow developer, I always absorb a few of their tricks and techniques. It's a fast track learning experience for both participants. But I've only done this in small doses. I'm a little wary of spending a full eight hours working this way. I suspect this might be fatiguing in larger doses, unless you're very fortunate in your choice of pairing partner.

I've written about the efficacy of code reviews before. That is something I have personal experience with; I can vouch for the value of code reviews without reservation. I can't help wondering if pair programming is nothing more than code review on steroids. Not that one is a substitute for the other-- you could certainly do both-- but I suspect that many of the benefits of pair programming could be realized through solid peer review practices.

But code reviews aren't a panacea, either, as Marty Fried pointed out:

My experience with code reviews has been a mixed bag. One of the problems seems to be that nobody wants to spend the time to really understand new code that does anything non-trivial, so the feedback is usually very general. But later, when someone is working on the code to either add functionality or fix bugs, they usually have lots of feedback (sometimes involving large hammers), but then it may be too late to be effective; the programmer may not even be around. I think it might be useful to have one anyway, but it's hard to get a fellow progammer to tell his boss that another programmer did a bad job.

The advantage of pair programming is its gripping immediacy: it is impossible to ignore the reviewer when he or she is sitting right next to you. Most people will passively opt out if given the choice. With pair programming, that's not possible. Each half of the pair has to understand the code, right then and there, as it's being written. Pairing may be invasive, but it can also force a level of communication that you'd otherwise never achieve.

On the other hand, peer review scales a heck of a lot better than stacking physical bodies in the same area. Consider the experiences of Macadamian with code review while working on the WINE project:

There were two processes in the WINE project that we weren't used to: public peer reviews, where new code and patches were distributed in a mailing list to everyone involved in the project; and single committer, where the project leader had the final say over which patches were accepted into the source tree.

We soon found out that Alexandre Julliard, who has been the maintainer of WINE and one of the key developers since 1994, was very particular about code going into the source tree. Our team's patches were scrutinized, and when some were rejected, there was a lot of grumbling. "My code works, who does this guy think he is? We're on a deadline here!" But as the project progressed, we realized we were producing our best code ever. Producing clean, well-designed code that was admitted into the source tree at first pass soon became a matter of pride. We also found that, despite the fact that the project was huge and spread worldwide, we knew exactly how the whole project was progressing since we saw every patch on the mailing list. We now conduct code reviews on every project, and on larger projects, we set up an internal mailing list and designate a single committer. It may be painful to set up code review at your company, and there may be some grumbling, but you will see big improvements in the quality and maintainability of your code.

I think both techniques are clearly a net good, although they each have their particular pros and cons. I encourage people who have experience with both pair programming and code reviews to share their experiences in the comments. Is one more effective than the other? Should we do both?

In the end, I don't think it's a matter of picking one over the other so much as ensuring you have more than one pair of eyes looking at the code you've written, however you choose to do it. When your code is reviewed by another human being -- whether that person is sitting right next to you, or thousands of miles away -- you will produce better software. That I can guarantee.

>Comments:

>I can't help wondering if pair programming is nothing more than code review on steroids.

The practice of pair programming was popularised via Extreme Programming, which has as part of its philosophy that "if a programming practice is known to be effective, take it to the extreme and do it as much as possible". That philosophy applied to both "code reviews" and "collaborative code design" give the practice of pair programming. http://c2.com/xp/PairProgramming.html

But it's a misconception to think that code review is the *only* benefit to be had from pair programming.

For pages discussing objections, see http://c2.com/cgi/wiki?PairProgrammingObjections http://c2.com/cgi/wiki?PairProgrammingQuestions http://c2.com/cgi/wiki?PairProgrammingDoubts http://www.c2.com/cgi/wiki?PairProgrammingMisconceptions
and for testimonials see http://www.c2.com/cgi/wiki?ProgrammingInPairsTestimonials .

(Read original post)

Code Reviews: Just Do It

In The Soft Side of Peer Reviews, Karl Wiegers starts with a powerful pronouncement:

Peer review -- an activity in which people other than the author of a software deliverable examine it for defects and improvement opportunities -- is one of the most powerful software quality tools available. Peer review methods include inspections, walkthroughs, peer deskchecks, and other similar activities. After experiencing the benefits of peer reviews for nearly fifteen years, I would never work in a team that did not perform them.

After participating in code reviews for a while here at Vertigo, I believe that peer code reviews are the single biggest thing you can do to improve your code. If you're not doing code reviews right now with another developer, you're missing a lot of bugs in your code and cheating yourself out of some key professional development opportunities. As far as I'm concerned, my code isn't done until I've gone over it with a fellow developer.

But don't take my word for it. McConnell provides plenty of evidence for the efficacy of code reviews in Code Complete:

.. software testing alone has limited effectiveness -- the average defect detection rate is only 25 percent for unit testing, 35 percent for function testing, and 45 percent for integration testing. In contrast, the average effectiveness of design and code inspections are 55 and 60 percent. Case studies of review results have been impressive:

• In a software-maintenance organization, 55 percent of one-line maintenance changes were in error before code reviews were introduced. After reviews were introduced, only 2 percent of the changes were in error. When all changes were considered, 95 percent were correct the first time after reviews were introduced. Before reviews were introduced, under 20 percent were correct the first time.
• In a group of 11 programs developed by the same group of people, the first 5 were developed without reviews. The remaining 6 were developed with reviews. After all the programs were released to production, the first 5 had an average of 4.5 errors per 100 lines of code. The 6 that had been inspected had an average of only 0.82 errors per 100. Reviews cut the errors by over 80 percent.
• The Aetna Insurance Company found 82 percent of the errors in a program by using inspections and was able to decrease its development resources by 20 percent.
• IBM's 500,000 line Orbit project used 11 levels of inspections. It was delivered early and had only about 1 percent of the errors that would normally be expected.
• A study of an organization at AT&T with more than 200 people reported a 14 percent increase in productivity and a 90 percent decrease in defects after the organization introduced reviews.
• Jet Propulsion Laboratories estimates that it saves about $25,000 per inspection by finding and fixing defects at an early stage.

The only hurdle to a code review is finding a developer you respect to do it, and making the time to perform the review. Once you get started, I think you'll quickly find that every minute you spend in a code review is paid back tenfold.

If your organization is new to code reviews, I highly recommend Karl's book, Peer Reviews in Software: A Practical Guide. The sample chapters Karl provides on his website are a great primer, too.