How Do You Explain Pair Programming?


I’m teaching project management (and some hiring) workshops in Israel. I’ve caught up with timezones, so I may even be able to post this week.

I attempted to explain why pair programming works to some skeptical project managers last week. I explained that in the best environments, a person can work 6 hours a day on technical work. And that person creates defects as well as creates work product. When pairing, the person can work for about 2 hours at a time, 2 or 3 times per day. But the created defect rate is much lower. The skeptics in my class pounced on the time spent working. I think I dealt with that question. But the real question that stumped them was how to do performance evaluations and give raises to pairs.

The problem I have is this: how do these managers give performance evaluations and give raises now? No one writes code or tests or whatever in a vacuum. All software is interdependent. So why is pairing somehow different? If we always performed peer review or inspections, wouldn’t it be the same problem?

I need more words or ideas to help explain pairing more successfully. Or, I need some more arguments to help people overcome their fear/resistance to this new-to-them idea. Got any words for me?

17 Replies to “How Do You Explain Pair Programming?”

  1. First of all, welcome to a wonderful country 😀
    Second, what about taking it one level up and ask them to evaluate the pairs as a team?
    You can try telling them that a temporary visitor see all flaws “Oreha Lerega Roeh Kol Pega”
    BTW, are you talking about permanent pairs? I thought that pair programming encouraged changing pairs.

  2. Some managers like pair programming because when the software is released, managers can go to almost any developer with almost any problem and the developer will be able to handle it. Pair programming destroys knowledge silos.

  3. Raises are often based on some non-obvious things, but let’s imagine you’re in a situation where a raise is based entirely on performance, and let’s imagine that the team does regular pair rotation. If your model is that you have to reward people based on contribution, you’re going to have a very tough go at it, since “contribution” can many aspects that aren’t visible aboutside the pair and outside the team.
    How about rewarding the team equally, based on the team’s performance? The team, if it’s a gelled one, will have already adopted a “we’re all in this together” mentality, sharing equally in the work. So why not share equally in the reward?
    Or if the team is mature and you trust them, you might consider an approach like “We’re giving you all an N% raise, and here’s a separate pile of bonus money. Figure out how to divide it up and let us know so that we can cut checks.” Risky, but the team might surprise you.

  4. Before I could answer any questions about how pairing affects performance evaluations and raises, I would need to understand the managers’ goals.
    The question that pops into my mind: “What do you want performance evaluations and raises to do for you?”
    Then a followup question might be: “How does your current system of performance evaluation and raises meet these goals?
    Those two questions will give you lots of information about the managers’ desires and assumptions around performance evaluations and raises. I’m confident that you would know what to do with that info.

  5. Have a look at for (guess what!) a list of benefits of pair programming.
    The Mary and Tom Poppendieck’s book “Lean Software Development – An Agile Toolkit” has a section on measuring performance on page 159. They reference Rob Austin’s book “Measuring and Managing Performance in Organizations”.
    They say about it: “If you read the book, you might have second thoughts about measuring performance.”
    Hope that helps. 🙂

  6. For one thing, pair programming gives you in-depth code review for free.
    If you do ephemeral pairs (grab a buddy when it’s time to code, rotate through pairs so it isn’t always the same two people) you get widely dispersed knowledge transfer for free.
    In general the combination of the two means that the beginning of the pair programming roll-out is slow but the long term combination is fairly productive.
    A lot depends on your individual developers, though, so the sale probably needs to keep them in mind. I don’t buy the “it’s useful unless the developers are really good” argument, but I do believe that some people (many quite good and very productive) are not psychologically suited for it.

  7. Hi Johanna,
    There’s lots of good stuff mentioned in other comments on the benefits of pairing. In the specific, I think performance reviwes are done exactly the way they’re already done (good or bad).
    The questioner does seem to be assuming pairs stick together for significant durations and this is not normally the case when pairing. I would expect to do no more than one days work without switching pairs. Ideally, I like to switch every half-day.
    Even when I’m swapping pairs promiscuously, I’m still responsible for the completion of the task/story I signed up for, so my performance is assessed the same way it’s usually assessed.
    Assuming the review involves gathering feedback from peers, pairing greatly improves the quality of that feedback. Working closely with many different peers means tyhe collected feedback is broader (having come from many people) and deeper (having come from working initmately with the person).
    Does any of this help ?

  8. Ron Jeffries used to say that 90 percent of programmers think they won’t like pair programming, and that 90 percent of those who try it long enough to learn how to do it well do come to like it.
    I didn’t think I’d like it, but I did. (It does take two to tango – pairing with someone who refuses to talk at all doesn’t work.)

  9. Over any reasonable time period, pairs in a team will rotate so that every member has had a chance to work with everyone else.
    If management is using some form of “micro-credit” system to build up the performance review (e.g. keeping track of each task, and adding up the total at the end of the year), then simply apply the points to each person in the pair – people who do well will still get more, people who don’t will still get less.
    I’d flip around the question: how do the managers take into account team work in a performance review now? Why can’t they just do more of that?

  10. First, Pair Programming teams aren’t permanent. I know of at least one shop that rotates team members in the morning and again at lunch! If you are swapping out who you partner with, there will be no trouble spotting the Good Developers.
    Second, to introduce the concept of Pair Programming, introduce the idea and let a few team members try out pairing for specific projects. I’ve found Pair Programming to be a great way (from time to time) to bring a very concentrated focus to a tough problem. This lets people try out the practice and see how it works in their shop.

  11. My company attempts to use peer review and most of the time right now (since we don’t pair), peers don’t pay as much close attention to the programming skills and insights of their teammates as I wish they would.
    Pair programming, in my experience, makes peer review suddenly more nuanced and useful because your team KNOWS from daily experience what each member can do well and needs to work on. So-and-so is a lousy or great communicator? Someone else is really incisive and helps you move faster than you ever could yourself? Another person is *great* at working through threading issues?
    When pair programming, as in all coding, I don’t think anyone ever really gets usefully graded on “productivity” (not that managers won’t try).
    So, we (whether we admit it or not) grade on qualitative rather than quantitative measures. That makes the manager’s job to give some quantitative weight to the importance of each quality in the overall composition of your team. Do you give the biggest raise to the guy who communicates best or to the one that seems to have the most arcane grasp of coding lore? They’re both important. But your organization may need the communicator more than the lore-monger. Or the other way around. I think that’s how raises are usually given out no matter *what* people give lip service to.
    Anyhow, I would explain pair programming to those who’ve never tried it (and I miss it myself) as the deepest, most difficult, exhausting and satisfying peer-to-peer mentoring on earth.

  12. I agree with Alan F. Performance reviews tend to be on the same basis as non-pair programming teams. I do think it’s important to discuss with programmers new to pairing how they will be evaluated and that being a collaborative team player is valued in addition to technical proficiency.
    I have an upcoming article the April issue of Better Software magazine that gives a managers intro to pair programming – I will email you a copy when I get home.

  13. I think the most effective way to handle performance evaluations is to do a 360 degree evaluation where a selection of peers and the manager evaluate an individual.
    So the effect would be that someone who adds value to every pair he works with would get a high evaluation, while someone who alwyas drags down his pair would get a low one.
    Turns out this works for normal teams as well 🙂

  14. Hi Joanna,
    To convince skeptical managers, that is the question…
    First it is important to be clear that pair programming is not a general panacea, but a tool that is particularly effective for certain situations. One type of situation where it works well is in a failing project where two programmers work together over an extended period of time (weeks) bringing it to a healthy completion. Another type of situation is where concepts are initially very vague, and the initial work is to firm up the concepts and develop the “vocabulary” and “rules” of the project. I have personally seen the benefits of pair programming in these situations. There are, no doubt, other situations where pair programming has a powerful impact.
    Secondly, (risking sounding cynical) it is necessary to focus on what’s in it for the managers. And what’s in it for the managers is quality software delivered on time, with minimal hassle from subordinates and superiors, and with a good prognosis for easy support and maintenance after release. Now the trick is to connect this objective with pair programming. How do you do this? You could start by polling the managers to find out how many would take debuggers away from their programmers. I doubt there would be anyone, since debuggers vastly increase the effectiveness of developers. Then equate — in the effectiveness factor sense — pair programming with debuggers.
    Thirdly, it is important to make it clear that pair programming cannot be mandated. Some kind of “carrot and stick” approach works best, with the vast emphasis on the carrot.
    Lastly, the managers need to feel they came up with idea of using pair programming themselves. The minute you start making a direct appeal, you’ve lost them, so circling around the issue until some of the attendees start making positive-sounding noises that include the term “pairing up programmers” will probably work best.
    Good luck!

  15. I will not go to many detailed argument. Just one idea.
    All those process, langages, specifications or user stories, all those meetings and discussions, written documents or phone conversations converge to one thing: humans writing some code.
    This is the most important task (all the others are here to support this one) and also the most dangerous.
    Personnaly, I prefer to have some mate around rather than taking this journey alone.

  16. Great ideas and a good comments. My comment on pair programming is that the ability to do accurate, individual evaluations (and raises) is not really a very significant issue. Ask your client who is paying the bill if he really cares how accurate your staff evaluations are OR if he cares if the product comes in better, faster, and on budget. My question is related to pair project managing. Paired PMs is a subject that I have not read or heard much about. There are some obvious advantages- continuity, overlap, division of labor. This applies to an organization with a functional PM structure and the PMs have several projects. Any info?

Leave a Reply