The dirty secret of pair programming

Pair programming is one of the more controversial extreme programming practices. Having two people work on the same piece of code at the same time looks very unpractical and inefficient to someone not familiar with this practice. Pair programming proponents like me are usually quick to point out the benefits like improved quality, less rework, better communication and better knowledge sharing within teams but I think the biggest reason pair programming works is usually kept quiet.

People work harder when there is someone looking over their shoulder.

I’m going to be completely honest with you here. When I work alone I spend a considerable amount of time surfing the web, reading email, twittering (you can follow me at @mendelt) getting coffee and talking to coworkers. This means I’m spending less time working but it also means I’m constantly interrupting myself during the time I am doing work making me even less productive.

Now we don’t tell our managers this because it wouldn’t do anyone much good, the problem is a bit more complex than just people slacking off. What I’ve observed is most people have a hard time pacing themselves. We do really focused work for five minutes and then take a break. Unfortunately breaks have a habit of taking more time than they should and productivity goes out the window.

To solve this problem we need a way to maintain a sustainable pace. Pair programming is a way to do just this. Forcing yourself to explain what you do to your pair is a great way to maintain a sustainable pace and work a bit harder.

22 thoughts on “The dirty secret of pair programming”

  1. The fact that I am reading and responding to this is evidence of my lack of sustained productivity.

    When I work by myself (in the office), I’m lucky to get 30 minutes of real work done every hour (some due to interruptions beyond my control, some due to my own lack of focus).

    1. Whilst I concur, it’s also important to note that a interruptions force a mental context-switch that may take as long as 10 minutes to get thoughts ‘in the groove’ again.

      If you’re interrupted for 10 minutes, you may actually lose 20 minutes.

      The suggestion is unsolicited, but if I were you I’d try to tell my peers/colleagues to approach me with their concerns at a particular time of the day; unless they thought it was critical.

      What do you say?

      1. Interruptions that take you out of the “zone”

        We put two guidelines in place to address the ever worsening interruption problem. An email went out to the entire company to limit questions and discussions with developers to anytime after 4pm (unless it is urgent). For team interruptions (developer to developer), I gave out neck ties to the team. If a developer has his tie hanging out, do not interrupt. This has worked wonders to overall productivity.

    1. 1+1=1.5 however the quality of the code is much much better and indeed we win in time! This shows statistics and my own practice.

  2. You haven’t met the guys I used to work with who spent most of their time making fart jokes and imitating Office Space characters whenever they got together.

    You also haven’t met the dedicated and passionate, and very bright programmers I’ve known who work very hard by themselves and would be slowed down by working with a partner.

    In short, you’re stereotyping here.

  3. Hi!

    Congratulations! Your readers have submitted and voted for your blog at The Daily Reviewer. We compiled an exclusive list of the Top 100 Programming Blogs, and we are glad to let you know that your blog was included! You can see it at http://thedailyreviewer.com/top/programming

    You can claim your Top 100 Blogs Award here : http://thedailyreviewer.com/pages/badges/programming

    P.S. This is a one-time notice to let you know your blog was included in one of our Top 100 Blog categories. You might get notices if you are listed in two or more categories.

    P.P.S. If for some reason you want your blog removed from our list, just send an email to angelina@thedailyreviewer.com with the subject line “REMOVE” and the link to your blog in the body of the message.


    Angelina Mizaki
    Selection Committee President
    The Daily Reviewer

  4. I can’t pair program so I started experimenting with pomodoro to pace myself, with a ticker ticking in my headphones to help me stay focused.

    I won’t tell you how many effective pomodoros (25 uninterrupted minutes) I get daily, I don’t want to get fired πŸ˜‰

  5. Article title killed me for 5 minutes πŸ˜€

    Really, it’s often no people behind your back to make work process stable and continuity. It’s another one thing which give pair programming idea few sense in my mind, after knowledge sharing concept =)

  6. What a load of piffle. I have seen some very unproductive single programmers who waste at least two hours a day. However, when I watch large groups of pair programmers I see far more waste than this. Quite often one person out of the pair is almost entirely waste and the other person in the pair still wastes a couple of hours anyway.

  7. Thanks for the reactions. I did expect more negative ones though πŸ™‚

    1 + 1 = 0 is of course nonsense. In the case of pair programming the fear is usually that 1 + 1 = 1 (two people doing the work of one). In my experience with pair programming 1 + 1 >= 2 in almost all cases. There are of course exceptions to every rule. But if you focus on the exceptions you can probably dismiss any practice.

    I wrote this post to show there are down to earth reasons why pair programming is an effective way to do work immediately. It’s a more social way to keep people focussed on their work. I do agree with Cyril A. Karpenko that on the long run improvements in knowledge sharing (and code quality) will far outweigh this short term benefit.

    Of course like any practice it’s still a tool in a toolbox. Don’t use it because I say so but use it because you’ve made yourself familliar with the pro’s and the cons and see a benefit.

    There are other tools like the pomodoro technique, thanks sginter and Anonymous for bringing that up, that have similar benefits. I’ve used the pomodoro technique myself and am very happy with the results. I have to say I got the best results combining pomodoro with pair programming though.

    One of the things I did notice was that people automatically assume that ‘good programmers’ are automatically the ones with enough self discipline to structure their work. I don’t think this is always the case. Many very creative, very intelligent programmers are terrible at doing this. Pairing is a great way to get them to share their knowledge and at the same time get them more focussed.

    1. I think many scholars highly appreciate this technique despite anything else,
      You don’t have to worry about the Skeptics, nobody is asking anybody to approve anything-you can adopt it or not period- no politicking.

  8. Hi Fabrice,

    Thanks for translating! Your French is clearly a lot better than mine πŸ™‚ It never ceases to amaze me how showing a little trust by releasing material under a creative commons license for example generates so much more value because it allows people to add to the original.

  9. I’m just glad this isn’t only me.

    My workplace has each person sitting alone in a cube all day, with no contact with other programmers at all, whatsoever. I keep suggesting peer programming, simply because I find myself doing what you’ve described above.

    I think the magic to peer programming is that your teammate satisfies your need for a little diversion. Sure, you’re coding, but you’re also making jokes and talking about the code, thus engaging those parts of the brain that are screaming for release when you’re all alone in your cube.

  10. usually the biggest complaint against pairing isn’t the productivity drain though. it’s ‘different priorities’ for different people. Uniting people on a common priority will probably get people to pair up more often.

    Where i work right now every single developer has their own priority. so why would they want to go pair with someone else why their work slips a date?

  11. We are a Scrum and XP shop. Our development team actively engages in pair programming and I am confident they would violently protest if we ever even considered dropping the practice. As the development manager, I sit right in the middle of the development pod (open office concept) and see first hand what goes on both with developers working alone and in pairs. For all the reasons you state, I fully concur, two heads are better than one.

  12. Hi Mendelt,

    Thanks for being so honest. I agree with you but I have also noticed that it is more difficult to interupt two developers working together than one. This seems to keep co-workers and bosses out of the way. I guess it’s just human nature , it seems rude to butt in on a conversation (which pair programming seems to be) while it’s real easy to start a conversation when somebody is alone.

    That’s my 2 cents.

  13. Couldn’t agree more. But pair working on a same peice of code at a given moment of time somewhat seems conflicting. Plus who would want to “sacrifice” their 10-minutes(tending to 20) break, or their coffee, or the gossips around? I mean, what exactly would motivate us for the Pair programming? One thing could be… the “appreciation” that the pair may get from the management? that may let them continue to Program-Pair’ly. Just thinkin out loud…

  14. I think what you say is true but, I think you’ve missed an important reason why pair programming works. When a programmer is working alone, they are dividing their attention between controlling / responding to the computer’s (and the software’s) interface and thinking about code. In a pair programming situation, one programmer is the “driver” and the other is able to use all of their brainpower to focus exclusively on the code. Usually, the one who is not driving the computer is the first to notice issues in the code because this person is not preoccupied with controlling the computer and this person has nothing to do when the other person is typing or using the mouse.

    I’ve noticed that it is much easier for me to spot issues when I’m not the one at the computer and I’ve noticed how even very smart programmers have a hard time seeing the issues I find easily because they are preoccupied with the computer’s interface.

    I think if you are open to noticing this phenomenon, you will see it all the time.

    I think this may be the main reason why pair programming produces higher quality code–the person at the computer is essentially handicapped by their divided attention (like a person trying to drive and talk on the phone at the same time) and having an extra person there makes up for that and allows the pair to be better than they would be individually.

Leave a Reply

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