Pair Programming vs. Code Reviews

blog
82

Having tried pair programming for the first time this weekend I wholly recommend it.

My friend and I managed to develop a simple 2d physics simulation engine in a few hours… virtually from scratch with very few problems other than the usual “getting it to build for the first time on another machine” because of the original project’s lazy set up… but the actual coding was faster and more productive with someone looking over my shoulder and stopping me from naming variables badly or optimising needlessly. :slight_smile:

83

Every study on pair programming is flawed. They always compare 2 programmers versus 1. Every single study does this.

That norwegian study linked to earlier put 98 programmers up against 196 programmers working in pairs and found that there was NO difference in output between the 196 programmers versus the 98. They did find that the 196 programmers “worked harder”… but that just means they weren’t as efficient as the solo programmers.

84

Interestingly enough, I don’t buy pair programming that much after experiencing it first hand. Before pair programming i had experienced code reviews as a developer and did code reviews as well. (off course how effective code reviews are depends on how “constructive” they really are, (refer to http://anirudhvyas.com/root/2008/05/04/ever-controversial-and-sometimes-annoying-code-reviews/)
But keeping that topic aside, pair programming can be harmful when a senior guy sits with a medium to fairly experienced guy and starts emphasizing on right way to do things. Off course there is no end in sight as the “right” way might not sit well with other programmer who might be passionate about programming styles too.

I have seen this happen quite often, a senior developer doing more things, which allows the so called “junior” or may be not so junior programmer to sit idle and become kinda lethargic in thinking. Off course bookish knowledge tells us that this should not be, because if one is programming on something, other might be thinking on something else, but how often is that true ?

Regards
Vyas, Anirudh
http://www.anirudhvyas.com

85

Personally, I love pairing, and have for years. I’m sure some people never will, but I find a lot of people who hate it are doing it wrong. So I made a list of 21 wrong ways to do it:

http://agilefocus.com/2009/01/21-ways-to-hate-pair-programming/

This is also a nice set of FAQs for the novice:

http://aydsoftware.blogspot.com/2009/01/riddle-me-this-mr-pair-programmer.html

For those who are worried about introverts, I wouldn’t sweat this too much; even introverts can pair. In fact, many of them are especially good at it, as they are thoughtful, considerate, and polite. Plus, interacting as experts around a shared task in a comfortable environment with familiar people isn’t usually too painful for them. Keep an eye out for introvert/extrovert pairing, though; the extroverts sometimes need a little help in learning to not hog the keyboard or wear the introvert out.

86

Once you decide to try, don’t mess it up!

http://mikevalenty.blogspot.com/2009/05/5-ways-to-fail-at-pair-programming.html

87

I’m still a student in CS, but I’ve already had experience in both of these team practices.

From my experience, it’s much easier to get read and understand code as it’s being written than once everything is already laid out. Pair Programming was the way we were able to get the tougher projects out fast and done right. Whenever one of us hit a wall, the other had something to continue moving forward.

Peer Review was a tool we opted for much less as once the many lines of code were laid out, it wasn’t as easy to simply look at it and know what the other had done and why, at least on the spot. Also, we risked keeping erroneous solutions in our heads for too long before they were corrected, something invaluable when time came for exams.

In my opinion, Pair Programming allowed up to produce and understand lots of good code and understand exactly what we were doing in record time.

88

I did a summer internship while in college, and we did pair programming there. I was paired with one of the other interns, and we worked together for 8 hours a day for 3 months. That was the idea anyways. It turned out that the guy I was partnered up with knew almost nothing about programming (don’t ask me how he got the internship), and so I ended up writing the entire thing myself.

Pair programming might work well if you have 2 competent programmers that work well together, but this has been my only pair programming experience, so I wouldn’t know.

89

Code reviews are a useful tool if they’re thorough. Most teams only dedicate an hour or two per week for this, so they don’t eat up a lot of resources. Of course, sloppy code reviews are worse than no code reviews at all, but that’s just common sense. If you have a good senior developer who cares enough to delve into the non-trivial modules, they are a generally good practice for most teams.

Pair programming, like many things XP/Agile, is wonderful according to its practitioners and testimonials, but doesn’t do so well in the realm of hard data. It’s a useful technique to aid a difficult debugging session (especially anything multithreaded), and also useful as a short-term training tool (I’m talking about maybe 1-2 weeks, tops). As a constant regimen, however, it’s monumentally inefficient and generally counterproductive.

If you take any pride in your craft, then please remember that these things are merely tools, not panaceas, and should never be hard-coded into your team’s development process. Don’t fall for the XP snake-oil; just because something a small dose of something is good for you, does not mean a megadose will be.

90

My 2c worth on the cost side. Yes, having two people working on the same thing intuitively doubles the cost, since they could be getting two different things done in parallel.

But it’s not that simple. For starters, a pair tends to actually be working almost full time while together, since it discourages both from slacking off and web-surfing while waiting for builds as a single developer may be prone to doing (speaking from experience). Quality is generally better than code that’s simply been reviewed, since in my experience, after-the-fact reviews tend to be somewhat superficial and lacking the understanding of why decisions were made.

And it’s good for training and knowledge sharing - when one person works start to finish on a job, they frequently end up as the only person who knows enough to maintain it. With pairing, at least two people know it, more if the pair are regularly being rotated (i.e A and B for a few days, then C replaces A, then D replaces B, etc).

In any case, those are the reasons my workplace does pair programming - we find that the benefits outweigh the cost of not having so much work being done in parallel. It may hurt a little short-term, but we find it’s much more sustainable over the long-term.

91

When I first read Kent Beck’s book on XP back in the late 90s I could be heard muttering, “he’s right”, … “he’s right”, … “he’s right”. However, as soon as I hit the bit on Pair-Programming it just felt wrong to me. My objections are selfish but here they are:

: I do not want a mosquito muttering in my ear as I write code
: I want to think at my own pace so that I can understand what I am doing
: I do not want someone else to lean over my shoulder as I work

Basically it is all selfish stuff about how I work best. For me best is a low interrupt rate and time to think about what I am doing. PP gets in the way of this by disrupting the way I think and not allowing me to soak an idea up until I can understand it.

I have done some PP work and the tasks I found it really suitable are exploratory ones where no-one has an idea about how to do something. However, the same effect could be achieved by jaw-jawing in front of a black/whiteboard.

I have worked with someone that believes the complete opposite of what I have written above. We get on well but we do not agree on this point. Having said that, he is great to work with on PP.

I work with someone else that is totally awful at PP. He slinks off 15m into a PP session to do “something more useful”. He thinks it a waste of time and does not participate at all. Of course he is a bit of an AA [http://www.joelonsoftware.com/articles/fog0000000018.html] and appears to think of pairing as beneath him.

For PP to work you need co-workers to agree to do it and you also need to believe that it is a good idea.

Frankly, I think PP is a bad idea for complicated tasks for which someone needs to think a lot. Individuals do not think at the same rate, nor do they usually work the same way. PP does not take individuality into account.

Having said that, PP can be a good way of brainstorming awkward tasks.

The trick is to choose the correct tool (i.e. PP, Whiteboarding, solo programming) for the task at hand.

Experience has taught me that SP combined with whiteboarding often works out better for most things. YMMV.

92

Continuing my previous post, the main downsides are that a) it’s hard to sell to managers, and b) it’s not a style that suits everyone.

We were lucky on the former, in that a new project was started under a pro-agile manager, allowing the team to organise under it’s own terms. As for the latter, we’ve found that it does seem to work for the majority of people, even those who didn’t think much of the idea before they joined us. The small minority who don’t tend to be people who simply don’t work well in a team environment in general, never mind paired with someone else. Not much you can do about that.

(Speaking fairly generally in both these posts - obviously there are exceptions to any rule).

93

I have some questions about people’s experiences on pair programming.

  1. In my time, I’ve noticed that some programmers are really just gifted and much better than their peers. If you mix one of these with a mediocre programmer, how well does pair programming work. Or, should one perhaps only match up programmers of comperable cognative ability. And, I really do mean cognative ability, not necessarily their current skill level.

  2. How big does an organization have to be for pair programing to work effectively? It obviously won’t work in a 2 person company (or perhaps not even in a 10 for that matter).

  3. Code reviews (for the bean counters who hire) seem more efficient on a per dollar basis. Has anyone managed to get cost savings by doing pair programming?

This is a col topic and one where the results cannot be easily measured. The results may be, in fact, very chaotic due to people’s varying abilities. But then, I suppose that since even Alan Greenspan cannot predict how people in the economy react through the best computer models (as he said in one of his interviews), we have little chance here.

Cheers.

94

Carleton -

  1. No doubt, the best work comes from pairing people with equal skills. That said, as long as the difference betwen the two isn’t too great, there’s good training benefit in mixing junior and senior. It’s more work for both though, since they need to find a compromise that doesn’t leave the junior lost or the senior bored.

  2. Our team has varied in size over time, but let’s say between 10 and 20 developers of varied experience (i.e 5-10 pairs). Ideally you want enough people that you can rotate people around, not having the same pairs working together for months. Down that path lies madness - working that closely with a single person doesn’t work well long term.

  3. The actual $ cost is a little out of my domain, so I can’t give a specific answer. But I’d not be surprised if it came out well - it’s my experience that code reviews are too superficial to make much difference to code quality, so teams relying on that have always spent almost as much time fixing defects as writing new code (and defects). In a pair-programming team, we certainly still get defects, but not so much - maybe a tenth of our time spent on that kind of activity?

95

Another helpful post, Jeff. Would you please fix the behavior of the "Read Older Entries " link at the bottom of your blog? When I click on this, it takes me to a specific older blog entry. It should take me to a previous page of blog entries.

96

I don’t see pair programming as an good option in many cases. The pair doesn’t get along, the flow breaks all the time, too much talk noise is generated, management doesn’t see the benefits, there are not enough resources for some projects/tasks so how can you put two people into every project/task, difficulties to create schedules who works with who, customers call and interrupt both programmers who are also maintainers in four other projects, etc…

And who reviews the code of the pair? We shouldn’t be confident that the code is of course perfect, because hey there was two people coding it. Some programming standards are still needed plus good architecture for the software and so on. And someone should make sure (review) that the code goes according to the architecture.

In the end programming really should be so simple, that you don’t need the help of a pair. Or you should team up with a person with other skills than you have to achieve some goal. But then that would be team work, not pair programming. Why would you use four people for a task of two?

Still I think that talking is good, because that way information is shared. But talking should occur so that you don’t disturb other projects or interrupt others. For reviews the reviewer can prepare when he has time and the review session is kept in a separate room not in cubicles.

97

It seems the argument for either is feedback. There are thousands of studies out there that prove that timely feedback saves $$$. It’s reflected in all the lean manufacturing methods, JIT inventory, etc. It seems logical (but may not be true), that the same can be extended to code. It also follows that the sooner the feedback comes, the more valuable it is.

I think the closest analogy that works for me is writing. I don’t know many authors/editors that can share a typewriter. But the feedback loop is still adequate for the task. Whether per page, or per chapter, the author seeks out feedback as soon as possible and the reviewers actually drop everything and try to look hard at the problem. That’s obviously the issue with code reviews, we have coders who don’t have much invested in other people’s code doing a crappy job of reviewing. Pair programming is one attempt to make the feedback loop tighter since we can’t seem to make the reviewers do better. So two other alternatives spring to mind, 1) A editor type position who has final say on what goes out the door and who’s job depends on the code being the highest quality (the single committer model), or 2) Increasing the number of reviewers and getting them to do qualitiy reviews. It seems the latter is a much harder thing to pull off (again pair programming tries to force the issue), because programmers look at a lot of tasks as beneath their consideration. We’re artisans after all, we don’t do administrivia and it’s a bad use of dollars to force us into it. But artists do take pride in reviewing others’ work, if only for their own inspiration. Anyway, it seems like team makeup is the best guideline for doing reviews, if you have one superstar who you can spare from actual coding, you make that gal the grand pumba. If you have a team of superstars then you can probably do peer code reviews, presuming everyone has enough respect to do the job properly. Anywhere else you’re left with trying to force crappy reviews or pair programming, basically relying on a process to fix your people. Pair programming seems like a better choice to me, if only because you might learn something.

98

It’s not “either/or” – one does not replace the other. You should do both.

The advantage of pairing is that it makes code reviews far more effective. Instead of spending most of the review time explaining (and often defending) what you’ve done to the team (since the last review), you can focus on more critical things. Everyone will be far more familiar with ALL of the code, not just their part of it. You’ll spend the time discussing important issues that everyone is already aware of.

In a nutshell, you spend the time solving problems, not explaining or defending them.

Cheers,
Clinton