Introducing Pair Programming

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