Pair Programming vs. Code reviews

Tom dow.t 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.
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
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
One person shows the other some tricks, nice workarounds, etceds.

The end result is that both developers are fully aware of
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
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 participant. 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 helpWondering if Pair programming is nothing more than code review on steroids.
Not that one is a substitute for the other -- You cocould certainly do
Both -- but I suspect that percentage of the benefits of Pair Programming
Cocould 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 negative; 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 pairHas
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 Alexander re Julliard, who has been the maintainer
Of wine and one of the key Developers since 1994, was very particle
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 conducting CT 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 netGood, Although
They each have their particle 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 valid tive than
Other? Shoshould we do both?

In the end, I don't think it's a matter of picking one over the other so muchEnsuring 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 -- youWillProduce 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 popularized via extreme
Programming, which has part of its philosophy that "if a programming
Practice is known to be aggressive, take it to the extreme and do it
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
Software deliverable examine it for defects and Improvement
Opportunities -- is one of the most powerful software quality tools
Available. Peer review methods include inspections, writable throughs, peer
Checking checks, and other similar activities. after experiencing
Benefits of peer reviews for nearly specified teen years, I wowould never work
In a team that did not perform them.

After participating in code reviews for a while here at Vertigo, I believe thatPeer code reviews are the single biggest thing you can do to improve your code.If you're not doing code reviewsRight 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 evivity for the efficacy of code reviews in code complete:

.. Software testing alone has limited extends tiveness --
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 upgrade tiveness 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
  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
  People, the first 5 were developed without reviews. The remaining 6
  Were developed with reviews. After all the programs were released
  Production, the first 5 had an average of 4.5 errors per 100 lines
  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
  Inspections. It was delivered early and had only about 1 percent of
  Errors That wocould normally be expected.
• A Study of an organization at at&t with more than 200
  People reported a 14 percent increase in productibetween 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
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.