BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Introducing Pair Programming

Introducing Pair Programming

Bookmarks

An agile team of bright, talented developers struggles to deliver. They’ve taken on unplanned work fixing production defects that weren’t caught; there is more front end development than back end development, so the back end developers are idle, while the front end developers struggle to keep up. Or, they need to make updates to the controller system, but Brian is the only person who understands that code, and he’s too busy to do it. Sound familiar, maybe? Pair programming is a powerful technique that can fix these issues, and bring even more benefits to this struggling team. Why aren’t more teams pairing?

In the book Pair Programming Illuminated, Laurie Williams and Robert Kessler assert:

We’ve seen that most people resist transitioning to pair programming – it involves breaking old habits and being more communicative and collaborative than we’ve been conditioned to be. … We know that there are people out there who would quit their jobs if they were forced to pair.[1]

Introducing Pair Programming to a team can be tricky business. What can you do to increase your odds of success when transitioning to this practice?

What makes it so hard?

First let’s stop to consider why pair programming is challenging to adopt. There are several reasons.

1. It’s a big change.
There aren’t very many work practices that have as much impact on contributors as pairing does. Traditionally, the developer gets “into the zone”: headphones on and turned up; caffeinated drink and snacks handy. Most software developers are not accustomed to having very much interaction with other people over the course of their work day. Maintaining a dialogue will take some getting used to!

2. It’s intense.
This is one of the things that makes pair programming so effective as a practice: Focus, focus focus! If you’re pair programming, you can’t look at Facebook, browse the internet, or stop to answer that email that just appeared in your inbox.

3. It’s exhausting.
That level of focus and intensity is above and beyond what most people sustain in their workday. Pair programming pushes you a little beyond your comfort zone and builds your focus muscles. But there is a limit, no matter how good you get at it. Kent Beck wrote, “Most programmers can’t pair for more than five or six hours in a day.”[2]

4. It requires soft skills that most of your team might not have fully developed.
Human beings are not born with empathy or good social skills. If you interact with others at work on a very limited basis, your development of these skills might be a little behind the curve. Imagine what it’s like to spend a full day sitting and trying to work closely with someone whose interpersonal skills are sorely lacking. Or, imagine being a junior programmer trying to keep up with an impatient veteran. This requires a lot of patience and empathy from both people.

5. All change is hard.
Any change management expert will tell you – asking people to change how they do things can elicit an immediate fear response, as people try to understand what the change will mean for them.

If it is so hard, why bother?

Why, then, should you try to surmount all those obstacles? Pair programming has a lot of benefits. Let’s remind ourselves exactly what the pay-offs can be.

  • Higher quality code
    In an environment where every line of code is reviewed as it is written, code quality goes up dramatically. The quality of the code review gets increased because the reviewer is fully in the context of the code and actively participating in its formation. Several studies such as this one by Alistair Cockburn and Laurie Williams have compared side by side code written in pairs vs code written solo, and concluded that the paired code had fewer defects, and better design than the soloed code. In the Cockburn and Williams study, the paired programs were "consistently 20 percent shorter than their individual counterparts, indicating a more elegant and maintainable solution." [3]
  • Higher “bus count”
    “Bus count” is a rather crude way of describing how well your team shares knowledge, expertise and code ownership among them – how many of us can substitute for others on the team if someone is missing (i.e., gets hit by a bus)? If your bus count is 1, that means there’s someone on your team who you can’t do without – if they leave suddenly, your project is in big trouble. Pair programming can get you to the point where bus count = #people on the team – everyone is able to step in at any time for any purpose.
  • Greater team cohesion
    After spending full days working with your team mates, you’re bound to know them better than you did before. Getting to know someone better helps understand them better. Cohesion should increase.
  • More job satisfaction
    Most programmers ultimately find that it is a release to share the burden of code writing with a colleague – once they’re used to it. They don’t have to take the entire responsibility on themselves. They can help each other.
  • Higher velocity
    Yes, actually, you do get higher velocity when you’re pairing than when you write code solo. This is counterintuitive. How can it be faster for 2 people to write one piece of code than for each of them to write code separately?
  1. You can think through a problem faster when you think through it with someone. Having a partner keeps you focused on the problem. Your partner gets you through little sticking points where you aren’t sure what to do or where your domain knowledge is lacking. You pause less frequently to do research or look up code syntax, or just generally to be puzzled.
  2. Fewer defects means more time spent on creating new features and less time spent fixing bugs! Hence, higher velocity. In the Williams and Cockburn study cited above, the time in person-hours spent writing code in pairs goes up only by about 15%. This extra time is more than compensated for in the reduction of bugs (also 15%). Because bugs take much longer to fix after the code is written, the overall time to working code is demonstrably less when developed in pairs.
  • More maintainable code
    When two people write code together, they have to agree on the approach, the structure, and even the variable and function names. This lessens the chances that choices will be made that only make sense to one individual. Pair programmers are also more likely to adhere to mutually agreed upon standards for syntax and formatting and other good code writing practices such as TDD.
  • High degree of learning and people development
    Pair programming is one of the fastest ways to pick up new skills in software development. But beyond just languages and technologies, pair programmers transfer a multitude of skills from problem solving and algorithms, to keyboard shortcuts and debugging techniques. Yes, you can read someone else’s code to see how they solved a problem. But sitting with them and working with them as they solve the problem gives you far more insight into how they thought through it.
  • More flexibility for people to move around between teams
    The ability to bring people up to speed with the technology and programming domain quickly means that people can move from one team to another with minimal impact. This flexibility has benefits for everyone. When one project suddenly needs additional horsepower, managers can “borrow” resources from elsewhere in the pool and quickly see results from those transfers. Similarly, if a developer seeks to learn something new, or just wants a change of pace, they can request a move to another team. These requests can be accommodated with minimal disruption of the teams involved.
  • Fewer meetings
    When team members spend all day talking to each other, information flows freely. So, it’s rare that they need to call a meeting to discuss anything. This is a big selling point for most developers, who generally prefer actually getting work done to sitting in meetings talking about it!

Hopefully at this point you are convinced that pair programming would be worth some effort to adopt. This list of potential benefits is handy to share with people when you discuss pair programming adoption. Keep these front and center for yourself and your team. If the going gets tough, remind yourselves what the payoff is.

So how can we do this?

There are a couple of options I can recommend that will help reduce the amount of pain and prevent bad outcomes from happening as you introduce pair programming. Whichever option you choose should be implemented in the context of what works and what doesn’t work when you introduce a new tool or technique to developers. To understand that, let’s look at the work of Gina Green and Alan Hevner.

Green and Hevner[4] studied the reasons why good programming tools/techniques often get rejected by programmers. From surveys of enterprise software developers, they derived the following rules of thumb for introducing a new technique or tool:

  1. Let them choose when to use it.
    Developers prefer to have freedom over when they pair. It’s important *not* to mandate pairing or force people into it. What’s most likely to happen if you do, is that they become disgruntled, disengaged, tune you out, or rebel. Pairing is the brain child of great software developers, not managers or process experts. Thousands of programmers have bought in voluntarily based on the benefits they can see it provides. This is the only true way to achieve adoption.
  2. Give them less control over how to use it.
    Establish clear standards for how to pair. Pairing doesn’t mean sitting next to each other while each of you is writing code and occasionally asking each other a question. It means both people are focused entirely on the same piece of code/train of thought, and only one is typing at a time. Talk about good pair programming etiquette, such as
    • let the junior partner “drive”, even when they need a lot of guidance,
    • share control equally – both control of the keyboard as well as control of the design.
    • be courteous to each other when disagreements arise.
  3. Encourage them to do it (especially their manager!)
    Any time you want change to happen, you need to make that message clear, and you also need to state it repeatedly. Even if you feel like a broken record, repetition is required until the practice really takes hold. So, make sure it's clear that pairing is what you want (while still refraining from making it a mandate). Particularly coming from their manager, developers will take this message to heart, if it is sustained consistently over time.

With these three rules in mind, here are some suggestions for how to go forward.

Option 1) Cell Division

This option is appropriate if you already have, or can hire, some experienced and enthusiastic pair programmers. Let’s call them Pair Experts. You’ll need at least 2-3 to start. The method works like this.

  1. Create a team of half Pair Experts, half Pair Novices (any willing member of your team who hasn’t paired before)
  2. At first, all code should be written in pairs that have one Pair Expert and one Pair Novice. Rotate pairs (switch around who is pairing with whom) frequently.
  3. When the novices start getting the hang of things, you can relax the 1-1 Expert-Novice rule, but keep the team stable for at least 3 months, or until your Pair Novices are truly bought in and “converted” to Pair Experts. This will take at least 3 months. Be patient. If you stop too soon, the practice is likely to fade with time.
  4. Now you have twice as many Pair Experts as you had before. If you have more Pair Novices to convert, split the team into two teams and add in Pair Novices to each new team, making sure you have at least as many Experts as Novices on each team. Then return to Step 2.

This process starts out slowly, but expands exponentially. Starting with 1 team, you can have 8 teams pair programming by the end of 1 year, 16 teams by the end of 15 months. While you’re at it, this is a great opportunity to spread other solid technical practices, such as test driven development and continuous integration. These skills will spread throughout the teams because people are keeping each other accountable.

Note: the practice of rotating pairs frequently is referred to as “promiscuous pairing”. The benefit of this practice is that knowledge spreads like wildfire in the team. It also can have positive benefits from not overtaxing relationships between people who pair together over long periods of time. Kent Beck likes to switch pairs every few hours, but once a day is certainly sufficient. Menlo Innovations rotates pairs weekly.

Option 2) Starting from nothing

So say you don’t have any experienced pair programmers. You’re starting from ground 0, but you still want a path to get there. Here is the method recommended by Laurie Williams et al in Pair Programming Illuminated.[5]

First step is to find a well-respected developer on your team who is willing to be your partner in this endeavor. Approach a perspective candidate for this role, and explain to them what you want to do and why. Remember your list of benefits (above). If they aren’t sure, ask them to think about it. If they decline to help you, then ask them to keep an open mind and not become an adversary. Then move on to the next candidate.

Once you have a developer identified – let’s call him/her your “Pair Advocate” - you move on to the next step. In this step, the Pair Advocate begins to introduce the idea casually to others in your organization. This is best done by offering to help another coder with what they’re working on, or asking someone for 1-1 help. In this way, the Pair Advocate surreptitiously initiates pairing sessions with other programmers. If the session goes well, the Pair Advocate can then have a discussion with the partner about pair programming and its benefits, and assess the person’s openness to the practice. The goal is to get a number of like-minded individuals in your organization open to the idea.

Once you have a group of folks who are receptive to pairing, the next step is to hold an open discussion with everyone. Provide a plan for doing pair programming on a temporary and volunteer basis – including how many pairs you’d like to start with, and for how long you will try it. Because it takes time to acclimate to the practice, 3 months or greater would be a good target. Let people openly discuss their misgivings about the idea, and talk about how you can address their concerns. Talk about how you will evaluate the pilot. What kind of results would convince them that pair programming is a good policy to adopt longer term? Talk about how to gather data so you can determine the go-forward policy for the teams after the pilot. Then ask people to volunteer. Incentivize if possible by letting the pair programmers work on a desirable new project.

Additional recommendations

Beyond the mechanics of introducing the practices, there are several key things you will need to consider:

  • Pairing is not for everyone.
    The fact is that some people in your organization may never get on board with this. You can deal with this by:
    • Coaching them, if they are willing.
      A good coach can work with a team to give them an outlet for sharing their fears and difficulties, and help them find ways to deal with them.
    • Give them somewhere they can go that they don’t have to pair.
      Maybe there are projects you can designate where solo programming will still be the norm.
    • Allow attrition to take its course
      Be prepared to see some people make the choice to leave. New resources who are in alignment on pairing can replace them.
  • Make it part of your hiring process
    A good approach is to do a short pairing exercise with the candidate in the first interview, using experts to observe the candidate for the ability to engage and empathize with their partner. Candidates who pass this screening would then be brought in for a full day of pair programming with multiple partners before the final hiring decision is made.
  • Make sure your employee rewards and recognition are in alignment
    When you recognize and reward individuals’ actions and accomplishments, you are undermining the pair programming model, and encouraging people to continue to work alone. So, you must restructure your recognition to be focused on teams rather than individuals.
  • You’ll probably need to rearrange the furniture
    People who are pair programming need a long, straight table where they can sit next to each other and have elbow room. Each pairing station should be equipped with 2 large monitors, 2 keyboards, 2 mice and one computer. Get rid of the walls if you can. Everyone will be talking, so they don’t need quiet. The hum of collaboration will become an energizing soundtrack for your teams.
  • Provide recreational outlets and make taking breaks ok in your culture
    Many people find it helps most if they get up and move around for a few minutes between pairing sessions. A ping pong table is a practical way to accommodate this need for a short, active break and let people have a little fun.
  • Remember the change management curve
    Plan for a temporary degradation in performance when you initially adopt this or any new practice. If you let people know that you expect this, you can actually attenuate the curve a bit.
  • Set organizational expectations
    While you are celebrating the new level of focus being given to productive work, you will need to coach the rest of your organization to respect pair programming and not expect emails to be attended to promptly. Find other ways of getting information to and from your team, such as leveraging stand up time, or a designated team lead/scrum master who can monitor requests from outside the team and funnel them at appropriate times.

Distributed Teams

What about teams that are not co-located? Can they take advantage of the benefits of pair programming? Yes, they can, if they are willing to put in some extra effort. Many tools exist that enable programmers to share their screens and an open audio/video link, setting up a virtual pairing environment. Some experimentation may be required to determine exactly what tools will work best for your technology stack. While video is optional, it is highly recommended – getting body language and facial expression feedback helps tremendously in understanding what’s going on with your partner. E.g., is he silent because he’s confused? He’s thinking? Or he’s gotten up to take a bio break? Veteran remote pairer Joe Moore’s blog is an excellent resource for teams considering remote pairing. It’s also a good idea to get those teams co-located temporarily – for a sprint or two if possible – to try pairing in person and get a feel for it before making it a remote practice.

In conclusion…

Pair programming is an extremely valuable practice to add to any software development enterprise. It dramatically increases quality, and velocity, and can even have a great positive impact on developer job satisfaction. To get those positive results, it’s prudent to be careful of how pairing rolls out to your teams. Avoid mandates and ultimatums in favor of repeated encouragement and incentives. Be mindful of the impact that this powerful technique can have on the day to day reality of those who practice it. Let your teams discover the power of it and get into alignment by choice. And remember, it’s not for everyone. So have a plan for how you will respectfully respond if some team members ultimately choose not to align.

About the Author

Melinda Stelzer Jacobson is an Agile Coach who believes that productivity and success are achieved by happy people in teams where trust, respect and communication are valued. Her belief is grounded in 15 years of software development experience spanning across telecommunications, banking, scientific devices, web sites and internet applications. Based in San Francisco, Melinda’s credentials include Certified Scrum Master, Certified Scrum practitioner, ICAgile Certified Professional in Agile Coaching, DAD Yellow Belt and Innovation Games Certified Collaboration Architect. In her spare time she saves cute fluffy orphan bunnies from being euthanized.

 

References


[1] Williams, Laurie and Robert Kessler, Pair Programming Illuminated, Addison-Wesley, 2003, pp 9-10

[2] Beck, Kent, Extreme Programming Explained: Embrace Change, 2nd Edition, Addison-Wesley, 2005, p. 42

[3] Williams, Laurie and Robert Kessler, Pair Programming Illuminated, Addison-Wesley, 2003, p 38

[4] "Perceived control of software developers and its impact on the successful diffusion of Information technology" Carnegie Mellon special report

"The successful diffusion of innovations: guidance for software development organizations" IEEE Software

[5] Williams, Laurie and Robert Kessler, Pair Programming Illuminated, Addison-Wesley, 2003, pp 53-54

Rate this Article

Adoption
Style

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

  • It's intense

    by David Dawson,

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

    I think this was a fairly balanced and well written view on the practice that I've found leads to the most misunderstood team disagreements (even more than the perpetual flame war around TDD!)

    I think that this speaks to the heart of why pairing can never, and should never, be a mandated, permanent state of a team dev process.

    The introvert/ extrovert split in psyche is something that is rarely brought up, and when it is it's often misunderstood. Being an introvert/ extrovert does not directly mean that you are quiet and withdrawn, or open and lively, it discusses where you draw your strength from, interaction or introspection. This is innate, set from birth, can't be changed. Many introverts are engaging, personable, for example many of the best public speakers are deeply introverted (see, Damien Conway, the best speaker I've ever seen, very introverted), but they do not enjoy constant interaction.

    Mandated, permanent pair programming removes the possibility for extended introspection, and so will burn out introverts very quickly, it will simply drain the life out of them as they don't have the opportunity to recharge. Extroverts, in contrast, will thrive off it and not see the problem. I see this split regularly, some members of the team love it, and others don't, often aligned on the extrovert/ introvert split.

    The answer, as I'm happy the author seems to understand, is to be sensitive to the individual, not to sacrifice them on the alter of The Process. I've seen too many teams and organisations that have done that, it's sad, you lose good people, strong developers, deep thinkers, simply because they aren't aligned with a dictat. This can't be good for the industry. I also fear this will feed into the 'brogrammer' thing that rears it's head every so often.

    All in all, I enjoyed reading this article and agree with the majority, it's nice to see a balanced view describing the very real potential gains, and also some of the equally real potential costs of the practice.

  • Not for everyone

    by Curt Rostenbach,

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

    My experience has been that you need a pair where one can see the overall plan and another that is more detailed oriented. Each guides the other with their particular strength.

    However most places I've worked see pair programming as cutting overall productivity in half. Too many places believe in one person, one problem, one cube assignments.

    I've been called on the carpet whenever I've assigned a pair (or more) to work on a problem.

    My argument of cross training, cross pollination of information, and "Who do you think is going to cut down more trees, two people with single handled saws or two people with a double handled saw?" falls on deaf ears.

    I've had success with the times I've gotten away with it, but you just can't take two people at random, throw them together and expect it to work.

    It helps to have the environment set up so that when there is a disagreement, the pair can go their separate ways to explore options and then come back together when either has a solution to be merged into the overall goal.

    Or have two people that can split tasks up, work independently, then zipper their code together, and work together to resolve problems.

    For that to work, you need people who can trust each other that the code they hand off to each other is tested and will work.

    I've seen instances where this works fantastically, but not for those who, as I call it, manage by magazine article.

  • Mixing pair and 'normal' programming

    by Roan Bester,

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

    On our team we do both pair programming and 'normal' programming depending on needs. I also agree and believe that pair programming, along with XP, TDD and the rest, are tools to be used when appropriate and not dicated by Management. When you're in a Scrum team you anyway make a plan to get the job done. If that plan includes pair programming and the team has the right level of trust, then so be it.

  • Excellent

    by Ramprasad R,

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

    I always insist in sharing the responsibility of code between ppl as that will help them not to leave others when the other is struggling, thus increasing the cohesion

  • rearrange furniture

    by Ralf Büscher,

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

    Melinda,

    first I want to thank you for this great read.

    As a developer I feel annoyed and disturbed by other folks, who talk.

    All this noise, like phones ringing, people laughing, folks having chats or discussions are annoying for me.

    So for me the ideal setup is a table in a separate office, no phone, a sign on the door that says "do not disturb".

    Then it is easy to dive into the focus zone. And if and when there are the two of us, we are still together, but isolated, which is good.

    I think it is important to understand that some folks really hate other peoples noise, because it is so distracting.

    You might not understand this or you simply don't feel that way, but all I ask, is to respect this point of view. :-)

    Regarding "parining is not for everyone", I would like to raise the question what "programing" is per definition: Is it the actual process of writing these lines of code?" OR could it also be the definition of APIs? pair programing is nothing more nor less than intense collaboration. Some coders might not like to share their focus zone, but then again, they might be willing to attend grooming meetings, which provides very valuable input.

    regards

    RB

  • Great article

    by Jason Knight,

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

    Thanks Melinda for a wonderful article. You've greatly helped me in helping facilitate/coach pair programming in a team I'm working with as a Scrum Master. I'd love to get your thoughts on our approach.

    Here is a link to a post I wrote on how we're going about learning to pair program as a team:

    jasontknight.com/pair-programming-first-steps/

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

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

BT