Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Pair Programming vs. Code Review

Pair Programming vs. Code Review

Leia em Português

This item in japanese


Pair programming and code review are each practices that improve the quality of software, as well as promote knowledge sharing. When the Agile vs. Lean, XP vs. Scrum, and vi vs. Emacs debates get slow, developers have been known to debate the merits of pair programming vs. code review. Theodore Nguyen-Cao described code reviewers as chickens, and paired programmers as pigs.

The story of the chicken and the pig is often told in agile circles. When it comes to making a breakfast of bacon and eggs, the chicken is involved but the pig is committed. Thus, the term 'pig' has come to be used for those who are fully committed to a given endeavor. The term 'chicken' is used to describe those who are involved, but for whom the stakes are lower.

In code reviews, people sit down to review someone’s code. Everyone has an opinion but not everyone is going to be working with the code on a daily basis. At the time, everyone seems to be involved in the process but there is no vested interest. They are just looking at some code and asking themselves "does this code look good and is it correct?". It’s a very passive standpoint. On the other hand, pair programmers are completely invested (committed?) in the task at hand. They immediately are using the code they are writing together and collaborating their thoughts on design, code layout, etc. Both programmers are taking on an active role and are emotionally invested in the task at hand because they are attacking the same problem together.

Theodore also points out that the feedback loop is much tighter during pair programming than it is during a code review. During pair programming, developers write, inspect, and change the code continuously. A code review, in contrast, involves inspecting the code later, usually when the author thinks it is ready for deployment.

It is generally accepted that the cost of a software bug goes up dramatically, perhaps exponentially, as the time between introduction and correction goes up. By this metric, issues caught during a pair programming session cost far less than those caught during code review. Of course, either of these is much less expensive than letting the bug get released before it is caught. Perhaps it pays to do both.

Do you prefer pair programming, code review, both, or neither? Leave a comment and share your thoughts.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Pair programming when you can, code reviews when you can't?

    by Evan Deaubl,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Both

    by Bryan Nehl,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Reviewers don't care?

    by Jason Cohen,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Re: Pair programming when you can, code reviews when you can't?

    by Shekhar Gulati,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Re: Reviewers don't care?

    by Curt Hibbs,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Apples & Oranges...well, ok, Lemons & Limes

    by Mike Bria,

    Your message is awaiting moderation. Thank you for participating in the discussion.

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

  • Quantify this Debate w/ Metrics

    by Ken Collier,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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?

  • Feature Teams use Code Reviews ... and pari programming when helpful

    by Stephen Palmer,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Re: Quantify this Debate w/ Metrics

    by Jeff Santini,

    Your message is awaiting moderation. Thank you for participating in the discussion.

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

  • Design review and/or code review versus pair programming

    by Knut Forkalsrud,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Re: Quantify this Debate w/ Metrics

    by Wojciech Seliga,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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!

  • pairing

    by Kevin Johnston,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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"

  • Pair-Programming is about Programmers (not Programming)

    by Srini Penchikala,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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:

    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.

    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 Or Code Reviews

    by Tony Ambrozie,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p