Pair Programming Explained

It was 1999 when I first heard about Extreme Programming [ Beck ] and its counter-intuitive practices of Test-Driven Development and Pair Programming. At the time, I was embroiled in a telecomms project, managing a large team of C++ programmers.

On that project, some developers were new to C++ and object-oriented programming but had valuable knowledge about our existing systems written in CORAL. Whereas other programmers were C++ experts who had mostly worked on strategic proof-of-concept projects so were unused to writing high performance production code. We developed our software incrementally, using UML to capture designs, and held code inspections of programmers' work, but we struggled with effective knowledge sharing.

Problems that arose were:

• Programmers who reported they were "90% done" on the same tasks for several weeks.
• Lack of dependency management - long compile times.
• Programmers using new language features purely to try them out without considering the impact on performance.
• Programmers who reported they were finished when they had done little or no unit testing.
• Programmers who kept code checked out for long periods.

Since then I have become an XP practitioner and, in hindsight, I realise that these problems could have been avoided if we had applied the practice of pair programming.

Pair programming environment

In 2000, I decided to follow Martin Fowler's advice: If you can't change your organization, change your organization! I went for a job interview as a developer at an XP company. The team had just moved into new offices and they were being fitted out to create a customised work environment to support the XP team. Large screens and convex desks were the order of the day.

To start pair programming, as Ward Cunningham said, you need to "Arrange the furniture" [ Cunningham ]. Pair programming is not one person passively watching the other type. Each programmer needs to play an active role in determining the design, implementation and tests. The pair works together on the task in hand while passing keyboard control back and forth between them, writing code and tests as they go. Many offices have desks shaped for a single programmer to sit within an inset. It is impossible to pair program at these desks without squashing your partner. Instead, you need straight-sided tables or better convex curved desks. You also need wall space for whiteboards and pin boards, to create what Kent Beck now calls an Informative Workspace.

Try to get workstations with the highest specification you can (you only need to budget for half the number of workstations as for solo programming). A large screen area is essential so that both programmers can read the code without crowding each other. Dual screens have become a popular way to implement this. A cordless keyboard and mouse can also make it smoother to pass them between partners. Some teams even choose to set up workstations with two keyboards and two mice (although I haven't tried this myself). To make it easy for a pair to use any free workstation, each workstation ought be configured with the same set of development tools and a standard set of preferences in the team's chosen IDE.

A pair programming episode

Most XP teams make a pair programming session part of their interview process. My first pair programming experience was during my interview. This was quite nerve-racking, as I was new to the Java programming language and web development. However, from a candidate's point of view I appreciated a chance to see their code and get an impression of how they worked before accepting the job.

Here is how a typical pair programming episode works. The person at the keyboard takes the role of driver and directly implements the solution working at the tactical level; their partner takes the role of navigator thinking at a strategic level about next steps and potential pitfalls. Pairs switch frequently between these roles (sometimes passing the keyboard over every few minutes).

Each pair programming episode typically lasts a couple of hours and ends with code being integrated and checked into version control. In addition to switching roles during a pair programming episode, programmers in an XP team typically change partners more than once per day. Most teams I have worked with use use a simple pair rotation rule - each day the pair splits, leaving one person on the task for continuity and releasing the other to pair with another programmer on a different task.

Some teams have experimented with swapping even more frequently, using a synchronised time interval of as little as 45 minutes. Arlo Belshee reports that when swapping partners every 90 minutes: We were able to fully ramp up new hires who had never programmed in C++ before - to the level that they could write template metaprograms and train the next round of new hires - in one month [ Belshee ].

My experience of joining two XP teams with an existing code base is that, initially each pair programming episode is like key-hole surgery - you can work effectively on small clumps of related classes to add a new feature but you don't really get a good picture of the architecture by pair programming alone. My advice is to be aware that pair programming is not a substitute for training, new programmers will need time to learn a new technology and will probably benefit from some time on their own to explore the code base when they join the team.

The rationale

Pair programming sounds like it will be hard to justify to your team and management. If you only count number of number features coded per developer then it might appear that two programmers will produce more features when working separately than when working as a pair. But this is a simplistic view of productivity that ignores the contribution of defect rates and rework. Maximizing your output without attention to quality eventually slows a development team down. We are all prone to making mistakes and bugs cost additional time to fix - usually interrupting on-going development tasks. Code also needs to be consistently organised and well factored to allow subsequent features to be added.

Fixing defects found in a QA phase or, worse, after deployment is costly. Leaving defects in the code to be picked up downstream also slows down a software development team, as programmers try to build new features on over-complicated and possibly malfunctioning code. Pair programming can prevent this slowdown by keeping code clean and well organised at all times. Clutter and bugs are simply not allowed to accumulate.

It is well recorded that code inspections are cost-effective ways to reduce defect rates [ Fagan ]. However, industry adoption of formal inspections still remains low. Most teams that I meet see code reviews as a "nice to have" practice and drop them when the team is working under time pressure. Pair programming provides an alternative way to implement design and code reviews. The ongoing peer review that happens while pair programming prevents poorly designed code from ever being checked in. When programmers write code in pairs, they keep each other on task and on process.

Information rapidly diffuses through a pair programming team as pairs switch and learn from each other. Ken Auer, one of the early adopters of XP, calls this knowledge transfer effect the "pair-vine." Although code inspections also support knowledge sharing, these meetings typically happen weeks apart, so they have an inbuilt latency. Also discussing a technique in a code review is not the same as actually trying it out. When you are pair programming, you learn good design by implementing new concepts on real code with your pair on hand to give guidance.

The evidence

There are some studies that provide empirical evidence in support of pair programming.

• A 1975 study of "two-person programming teams" reported a 127% gain in productivity and an error rate that was three orders of magnitude less than normal for the organization under study. [ Crosstalk ]
• In 1992, Larry Constantine wrote about a team that was set up by author P.J. Plauger, who developed code that was nearly 100% bug free. [ Constantine ]
• Dr. Laurie Williams, author of Pair Programming Illuminated , has carried out the main research on this topic. You can find much of her research on the pair programming website [ Pair ]. Williams found in her studies [ Cockburn ] that in exchange for a 15% increase in development time, pair programming improved design quality; reduced defects by an average of 15%; and was reported as more enjoyable by programmers at statistically significant levels. A less well-known finding was that pair programmers generate output that is more concise - implementing the same functionality in fewer lines of code.

Personally, I am a bit skeptical about these studies - the conditions that they were carried out under are unlikely to be representative of many software projects in industry. Over the last six years, I have witnessed pair programming working effectively on real projects in a variety of domains that have successfully delivered software and it has become my preferred way to write code.

Programmer's concerns

Code quality is important but most developers who have not tried pair programming are concerned about how pair programming affects their creative process and how working with another programmer affects the pace of development. There's no denying it feels different. Your partner frequently challenges your proposed approach so you have to stay alert and completely engaged in the task at hand. It's hard work but nice to have someone to share your highs and lows with.

Programmers may worry that pair programming will expose gaps in their coding skills. This actually cuts both ways - it's highly probable that you know tricks that your partner does not. My experience is that once programmers have tried pair programming this concern quickly evaporates as such gaps are quickly filled when you are learning from your programming partners. Working with a partner means there is always someone there to help you get unstuck. By staying focused on the task at hand you are more likely to have working code at the end of the day rather than going home with coding problems still lodged in your head.

As knowledge spreads throughout the team, fewer bottlenecks are caused by holidays or absence because most code has been worked on by more than one programmer. You stop having to plan around key people on the critical path. Because pair programming brings an increase in knowledge sharing, it can release you from specialist work that no one else knows how to do. No longer will you be the only person who can work on a specific component and feel under pressure whenever you need to ask for time off work. You will be free to move onto work on other parts of the system and broaden out your skill set.

Finally, curbing programmers with bad habits who create work for the rest of the team, by checking in their broken code for their fellow team mates to fix, can be a big relief if you were one of those dutifully cleaning up in their wake.

Getting to the next level

It does take time to become skilled at pair programming. The technique hinges on improving your communication skills; it is vital that you can articulate your ideas and also listen to your pair. I recently spent several months working in a dispersed team where each developer worked from home and we pair programmed using NetMeeting to share desktop control. Despite my initial doubts, this actually turned out to be a reasonably effective way to work. Although it did require even more attention to clear verbal explanation of potential problems that you see in your partner's approach and alternative strategies that you would like to be considered.

When solo programming, we invest more effort in building a complete mental model of the solution and then transcribing it into code. However, we don't always think every scenario through thoroughly and so bugs can creep in. Pair programming slows down our thinking process so that we take a closer look at each small step in building the solution - working in the "here and now" using the simplest strategy that works for this moment. Each programmer reveals their experience a little bit at a time and their ideas are woven together rather than clashing over anticipated end solutions. You have probably heard about the XP saying "Do the simplest thing that can possibly work" - this heuristic is the key to resolving differences of opinion that arise in a pair programming team. This is used as a guide to evaluate micro-decisions at the strategic level within a pair programming episode and does not literally mean write naïve solutions.

You may anticipate that pairing inexperienced programmers with expert programmers may be frustrating because the expert will be forced to slow down to work at the pace of the novice. It is essential that the expert does take time to explain their thinking to their partner rather than dominating the keyboard or barking keyboard escape sequences for them to type. The novice is more likely to get up to speed as an effective team member when their partner takes care to explain their thinking and the expert is likely to be surprised that slowing down often results in a more rounded solution. The peer programming experience of two experts working together is usually very rewarding, as both partners will be generating good ideas and counter-challenges at a similar rate. Novice-novice programming pairs are typically more talkative as the pair are working hard to learn together - often making false starts when in new terrain but usually making more progress than when left to work on their own. It may be wise to track pairing combinations within your team to avoid pair cliques forming and to ensure that each team member gets the opportunity to pair with everyone.

Solo programming

Are there times when solo programming is appropriate? Yes. Sometimes code quality is not so important - as when developing a temporary solution or prototype. Splitting a pair makes sense when exploring alternative technical solutions or bug-busting where different root causes need to be eliminated. There will be days when you have an odd number of programmers. Most programmers find being locked into pair programming all the time a little claustrophobic and appreciate some time to work on their own now and then. In this case, try to make sure that any production code written without a pair is peer reviewed before being checked in.

After reading this article it might appear that pair programming will have a positive effect on every software development team. But as the mighty Frederick Brooks said, there is no "silver bullet." [ Brooks ]. Some scenarios are listed below where pair programming is unlikely to deliver the full set of benefits:

• Flexi-time and Telecommuting . For pair programming to get off the ground successfully, you do need to have programmers available for work in the office for core hours. This may be an issue if your company explicitly offers employees the option to work from home and programmers on the team do not wish to give this benefit up.
• Distributed Teams . Where a project team is split across different company sites, it may not make sense to attempt pair programming across these boundaries, as face-to-face communication is much richer. An alternative is to only pair program within the sub-teams at each site and then implement code reviews of selected work products across the boundaries. This strategy does mean that you lose some knowledge sharing across sites but rotating programmers between sites is another way to do this.
• Diverse Teams . A classic situation in which pair programming does not work well is when you have heterogeneous system architecture and the team is made up of a small number of specialists, each proficient in only one technology used in the system. A common case of this situation is the specialised database programmer. It probably does not make sense for an Oracle programmer to pair with a C++ programmer because the skills required to work proficiently in their respective technologies are not easy to absorb via pair programming alone and separate training support may be required.
• Small Teams . Very small teams (one to three programmers) will probably find that they do not benefit from formal pair programming as they already have a high level of interaction and would find working with the same person for long periods too claustrophobic.

Summary

Pair programming is a technique that improves both code quality and your programming skills. It helps by improving programmer discipline and providing a mechanism for knowledge sharing. The best way to evaluate pair programming is to use this practice on a small, low-risk project. To check whether the practice is delivering results, review your bug rates - you should find fewer critical bugs reported on code developed in pairs. It will also be important to discuss with the team what their experience has been with pair programming and whether they feel that they are learning more by using the technique.

References

[ Beck] Extreme Programming Explained - K. & C. Andres ISBN 0-321-27865-8

[ Belshee] Promiscuous Pairing and Beginner's Mind: Embrace Inexperience by Arlo Belshee, Agile2005 http://agile2005.org/XR4.pdf

[ Brooks] The Mythical Man Month by Brooks ISBN 0-201-83595-9

[ Cockburn] The Costs and Benefits of Pair Programming XP2000 conference, A. Cockburn & L. Williams http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF

[ Constantine] "The Benefits of Visibility" in The Peopleware Papers - Larry Constantine ISBN 0-13-060123-3

[ Crosstalk] Crosstalk March 2003 available on-line at http://www.stsc.hill.af.mil/crosstalk/2003/03/jensen.html

[ Cunningham] "EPISODES: A Pattern Language of Competitive Development" - Ward Cunningham, Pattern Languages of Program Design 2 . ISBN 0-201-89527-7

[ Fagan] "Advances in software inspections to reduce errors in program development" - Michael Fagan IBM Systems Journal 1976.

[ Pair] http://www.pairprogramming.com/