The Artima Developer Community
Sponsored Link

Java Community News
Jeff Atwood on Pair Programming vs. Code Reviews

11 replies on 1 page. Most recent reply: Nov 28, 2007 6:40 PM by Bjørn Stabell

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 11 replies on 1 page
Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Jeff Atwood on Pair Programming vs. Code Reviews Posted: Nov 20, 2007 9:59 AM
Reply to this message Reply
Summary
Pair programming, a key tenet of Extreme Programming, aims to produce better code due to two people looking over every line in the source, at the time code is being written. Jeff Atwood compares that technique to code reviews that also result in more than one developer looking at a piece of code, albeit at different times.
Advertisement

Pair programming—the practice of two developers working as a pair, with one at the keyboard and the other looking over the first developer's shoulder—is a key discipline of Extreme Programming. While many developers agree that there is value in having two pairs of eyes looking at every line of code as that code is being written, relatively few practice pair programming.

In a recent blog post, Pair Programming vs. Code Reviews, Jeff Atwood compares pair programming to code reviews, suggesting that both can accomplish the goal of more than one person looking at every line of code:

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...

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.

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.

Do you practice pair programming on your projects? If so, how would you compare the value of pair programming to that of code reviews?


Antonio Cavallo

Posts: 10
Nickname: cavallo71
Registered: Mar, 2006

Re: Jeff Atwood on Pair Programming vs. Code Reviews Posted: Nov 21, 2007 1:12 AM
Reply to this message Reply
Pair programming is the very same equivalent
of the scientific habit of peer review:
it has been around since ever and it works well
amongst scientists trained to do so.

As matter of fact in programming I found very
effective this practices:
briefly commenting the change list every time before
committing the changes.

Most of the problems are due to un-clear design
and/or over look of simple mistakes: the process
of reviewing them twice after a little short pause
reduces greatly them.
Additionally commenting them does a verify
on the design choices.

Regards,
Antonio Cavallo

Bill Pyne

Posts: 165
Nickname: billpyne
Registered: Jan, 2007

Re: Jeff Atwood on Pair Programming vs. Code Reviews Posted: Nov 21, 2007 6:36 AM
Reply to this message Reply
> Pair programming is the very same equivalent
> of the scientific habit of peer review:
> it has been around since ever and it works well
> amongst scientists trained to do so.

My understanding of peer reviews, based on friends and family members who do research, is that they can occur after certain stages are reached in the course of a research investigation and always before a paper goes to publication. None of the people I refer to have someone peer reviewing 8 hours/day 5 days/week. It seems like code reviews are much more the equivalent to peer reviews.

Bill Pyne

Posts: 165
Nickname: billpyne
Registered: Jan, 2007

Re: Jeff Atwood on Pair Programming vs. Code Reviews Posted: Nov 21, 2007 6:54 AM
Reply to this message Reply
I don't see it as Pair Programming vs. Code Review: putting the focus on the process and away from the people is a mistake. There's no "silver bullet" here. What's presented are two different techniques that individuals can employ according to how he/she works best.

Personally, I couldn't work side-by-side with anyone for more than a few hours; it's too distracting and extremely tiring. Code reviews I like because I want people to look at my design and implementation (code) with objective minds. Often just the work involved in preparing for a code review causes me to look at my own work with more objectivity.

Daesung Park

Posts: 10
Nickname: grayger
Registered: Apr, 2006

Re: Jeff Atwood on Pair Programming vs. Code Reviews Posted: Nov 22, 2007 4:33 AM
Reply to this message Reply
I am not an advocate of Pair programming. It needs physical accessibility. Early bird gets along with night awl.

Moreover, the paper "Are Two Heads Better than One?" appears in IEEE Software (http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?isnumber=4375227&arnumber=4375233) show that pair programming is effective only under some conditions.

Vikas Hazrati

Posts: 3
Nickname: vhazrati
Registered: Oct, 2006

Re: Jeff Atwood on Pair Programming vs. Code Reviews Posted: Nov 27, 2007 10:01 PM
Reply to this message Reply
In my view comparing pair programming with code reviews is comparing apples and oranges.
One of the advantages of Pair Programming is that it helps in doing effective, instant code review, however the benefits of pair programming are not limited to effective code review. There are more like

1. You can get a new member upto speed very fast
2. There is collective code ownership, you are never married to your code.
3. You feel motivated to think about the problem all the time when working in a pair, remember a good pairing session can leave you exhausted. We don't do pairing sessions of more than 2 hours at a stretch.
4. You are constantly validating your design decisions and ideas with another person which always enhances the quality of the solution.
5. You are doing everything in the flow as XP says. Code review is not a separate process as in a manufacturing cycle. But testing, designing, coding, review etc everything is done together.

James O. Coplien

Posts: 40
Nickname: cope
Registered: May, 2003

Re: Jeff Atwood on Pair Programming vs. Code Reviews Posted: Nov 28, 2007 10:24 AM
Reply to this message Reply
There was some good research on a closely related topic in my department in Bell Labs research back in the 1980s. Larry Votta and Nancy Staudenmeyer compared the effectiveness of a code inspection meeting with independent, uncoordinated "desk checks" done by individuals. The statistically significant results show that you get 80% of the bug coverage with much reduced effort and without having to coordinate the attendance of multiple people at a single meeting.

See http://portal.acm.org/citation.cfm?id=167070&coll=portal&dl=ACM for one of the several publications on this topic; a more recent one (1997) in IEEE can be found at http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel3/4837/13372/00610188.pdf&arnumber=610188.

I hope that folks writing these 'blogs and articles are doing good literature searches; this is a well-mined area, and we can do better than just postulating.

David Beutel

Posts: 29
Nickname: jdb
Registered: May, 2003

Re: Jeff Atwood on Pair Programming vs. Code Reviews Posted: Nov 28, 2007 10:35 AM
Reply to this message Reply
Code reviews are usually done after the code is finished, so the comments are like criticism and the author feels defensive. They're only good for minor improvements or bugs. A reviewer may suggest a better design or approach, but it's too late because it's not worth redoing anything major when it already works.

Pair programming avoids this problem. You can get a better design or approach. Nobody suggests doing it 8 hours a day, though. That would be exhausting, but the few times I've done it have been positive. It depends on the task and the person you're paired with, of course.

David Beutel

Posts: 29
Nickname: jdb
Registered: May, 2003

Re: Jeff Atwood on Pair Programming vs. Code Reviews Posted: Nov 28, 2007 10:56 AM
Reply to this message Reply
> I hope that folks writing these 'blogs and articles are
> doing good literature searches; this is a well-mined area,
> and we can do better than just postulating.

That ACM link gives me a server error, and that IEEE publication is not public. I guess that research will just go to waste, locked up in the literature. What a shame.

Luis Sergio Oliveira

Posts: 22
Nickname: euluis
Registered: Jan, 2004

Re: Jeff Atwood on Pair Programming vs. Code Reviews Posted: Nov 28, 2007 5:00 PM
Reply to this message Reply
> > I hope that folks writing these 'blogs and articles are
> > doing good literature searches; this is a well-mined
> area,
> > and we can do better than just postulating.
>
> That ACM link gives me a server error, and that IEEE
> publication is not public. I guess that research will
> just go to waste, locked up in the literature. What a
> shame.

I'm not a subscriber of any of the two and yes, it is a pity that we still have this system that puts scientific results behind a pay check. But, there are many freely accessible papers about pair programming:
http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF
http://collaboration.csc.ncsu.edu/laurie/Papers/Kindergarten.PDF
http://www.soe.ucsc.edu/~brianh/papers/ICSE-Doctoral.pdf
http://repositories.cdlib.org/postprints/348/

and more, just google on papers about pair programming...

I reinforce the post by David Beutel and the notion that review is much less capable of influencing the end result. Also, another thing is passing knowledge around and exchanging ideas - pair programming is better.

When I do reviews (and currently this is the practice at my job) the best value is if the review is done by more experienced developers and they can somehow enforce their review comments to be taken into account - implying a further review. Some reviews I'm currently doing are more in the line of bureaucratic verification and this feels bad - they just want a name to put in the verification form, are normally inpatient to finish and start by showing the code and not the bug report or task description. And I understand a bit of that, if the change/modification is small the whole point of solving the issue is not in the created code, but, in the analysis done to reach to the particular solution.

That brings me to other related practice that I have found very powerful: pair debugging and analysing of errors ;-)

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: Jeff Atwood on Pair Programming vs. Code Reviews Posted: Nov 28, 2007 6:27 PM
Reply to this message Reply
Science, like everything else in the world, costs money.

The places I worked at had reviews early enough in the process that you could make changes if you needed to. Personally pair programming annoys the hell out of me. I can't stand it. I find it very hard to get in a zone and crank something out with somebody asking questions or pointing out a problem or sipping their soda or doing circles in their chair or waving their hands in front of the monitor to make a suggestion while I'm coding.

I find reviews much easier to deal with and very helpful. But that's more personal preference than anything else. About the only rationalization I have for not liking the practice is that it feels like you are moving half as fast as you would be able to if everybody was working on something. I don't know how that all comes out in the wash when you consider the amount of time it takes to do the review and fix things if changes are required.

Bjørn Stabell

Posts: 29
Nickname: bjoerns
Registered: Aug, 2003

Re: Jeff Atwood on Pair Programming vs. Code Reviews Posted: Nov 28, 2007 6:40 PM
Reply to this message Reply
Arlo Belshee has done some experiments with "promiscuous pairing" and other methods to increase the efficiency of pair programming, see:

http://stabell.org/2007/07/13/arlo-agile-experiment/


At Exoweb, we've used code reviews for the last couple of years (using a plugin to Trac that allows us to review each change set), and have had fantastic results in terms of improved quality and cross-learning. We've experimented with pair programming on-and-off in many different ways, but haven't achieved the same efficiency that Arlo's team did yet.

Flat View: This topic has 11 replies on 1 page
Topic: Matt Raible Compares Six Java Web Frameworks Previous Topic   Next Topic Topic: Reengineering Java EE Servers

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use