Pair Programming techniques

Pair programming has been widely touted as a effective means of generating excellent code in a cost-effective manner. It has also been widely reported as a waste of time or as uncomfortable. Many people reject pair programming without trying it. Others, however, still don’t like it after being forced to use trying it.

I’m convinced that there’s an art and a science to pair programming. I don’t think it comes naturally to most people. It’s sometimes easy to pick up by osmosis, but I’ve heard too many complaints about pairing to think that’s a common occurrence. I’d like to hear your real-life stories about pair-programming situations. If you don’t feel comfortable leaving your story as a comment on this blog, send them to “pairprogramming at”.

I also think there are specific techniques that make pair programming work better and go easier. One example is the “10-second rule.” The navigator should wait 10 seconds before pointing out a typo. Generally that’s long enough for the driver to correct a typo that’s already noticed. Excessive interruptions are distracting.

Another technique is for the driver to “think out loud” as she’s coding. This helps keep the navigator in the loop, and communicates the intent better. It’s certainly not a technique that most people practice without suggestion, however.

I’d like to hear of techniques that you’ve found effective, also. As mentioned above, send to “pairprogramming at” if you don’t feel comfortable posting them in public.

10 Replies to “Pair Programming techniques”

  1. My company discovered pairing by accident, about 5 or 6 years ago. We’d never considered trying XP at the time, and didn’t know anything about it, but we hit on pairing as a useful technique for knowledge transfer after I spent a while producing a framework that another programmer then needed to use… I sat with him while he wrote some code using it, making suggestions about how best to approach the problem, and we both felt afterwards that it was a valuable experience. We’ve been pairing on and off ever since, gradually learning throughout that time how best to approach it.

    It came something as a suprise when I learned that this was common practice in XP… I though it was something that only we did. Since then, we’ve adopted a few other XP practices (e.g. TDD, short iterations), and are working on the rest of the methodology.

    The 10 second rule you mention above is something I discovered fairly quickly, in a slightly different form… I generally wait until the driver has saved the file, and is about to compile before pointing them out. As you point out, they’re often fixed before then anyway, but still I found it’s faster if I point them out than the compiler (I did experiment with not mentioning them at all, but that was less productive).

    One thing we’ve found is that only the navigator really needs to know any particular API. This reduces the burden of learning different APIs: each of us chooses APIs to specialise in, and then navigates on any code that needs to use this API. We find it’s more effective if the navigator knows it than the driver, but I guess with different working styles it might be the other way around.

  2. That’s very interesting, Jules. It’s fascinating to me how people will come up with the same or similar techniques independently.

    I noticed the mention of a separate compile–what language/environment were you using? And how frequently were you compiling?

    I’ve gotten very accustomed to the incremental compilation of Java within Eclipse. It’s not so bad for the compiler to highlight the typo there, but I find it useful to point it out before moving away from the code with the error. And even when the error is highlighted by the compiler, it’s a lot quicker for the navigator to point out the typo than for the driver to process the compiler error message.

  3. Yes, with modern tools it’s not such an issue. Back when we started pairing, we were working in Java with a text editor and Sun’s command line tools. We’ve recently switched to eclipse, and yes, the incremental compile is a wonderful thing. 🙂

  4. As for frequency of compiles, we usually compile fairly regularly. Even if we’re not expecting to have code that runs, getting feedback from the compiler on errors sooner rather than later is often helpful.

  5. I refused to do pair programming when our manager tried to use pair programming as a way to fix some poor performers in the team. My contention was that they should be moved out if there was a performance issue. I was also unaware of XP then – but when I read Kent’s book recently, I could easily relate things. But I am finding it difficult to sell it to my management yet.

  6. Thanks, Jayadeep.

    What were you feeling when you refused? Did you think that you couldn’t teach those programmers to be good? Did it feel like your workload was being increased to make up for others? Or what?

  7. We actually use a modified form of pair programming. On a team of 7, we will rotate one(ie. 6 computers) so that there is always someone pairing. To lessen this even more, sometimes we may only do this every other month. Basically, just take a computer away from our WAR room and you have to join someone else. pair programming has been phenomenal for the new guys that join the team. They come up to speed much much faster…..but all in all, I think people forget that they don’t need to fully commit and can partially do it. There is definitely benefits of knowledge transfer and the team owning the code the more you pair program. Sometimes, it does feel like a waste if done too much though(at least that is this teams take on the subject), but we do like the knowledge transfer that continuously goes on.

  8. I work in an XP shop. Here are a few of the practices that I have found to work pretty well:

    We try to have a veteran pair with a novice most times. We try to make our stories/tasks small enough to complete in half-a-day or a day, but if the pair is working on a task that takes longer then we try to rotate out the veteran for another veteran and leave the task with the novice. I feel this helps the novice in several ways. First, they have to understand the task and not depend on the veteran to carry it out. Second, it helps them focus on the task and see it through to completion instead of trading out tasks everytime they are just getting the hang of it, which can be frustrating when you are new and want to feel like you are contributing.

    We use 2 keyboards and mice at every workstation so letting your partner know you are going to take over control is a must. It is very frustrating to think you are clicking in one place only to have your partner move the mouse halfway accross the screen.

    “Thinking out loud” is very important. If I see someone poking around through files for very long without saying anything, I will ask them to talk through what they are doing so I can follow it.

    I have found that “ping-ponging” control between the tester and the coder is fun and beneficial when both developers have a firm grasp on the story or the code being modified, but sometimes when working with a novice I find myself writing more of the tests and vice-versa in situations when I am less familiar with the code being worked on. On that note, the novice will need some experience writing the tests sooner than later…

    That’s all i have for now, maybe I will post more if I think of them. I am also open to any opinions or constructive criticisms of my tactics.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.