In "Pair Programming Dos and Don'ts," I presented twenty-one tips for how (and how not) to approach pair programming. I suggested that the practice of pairing is primarily about ensuring that all code gets reviewed. But, is that benefit enough to justify pairing?
On the surface, pairing seems wasteful. Two developers to complete a single task? The primary payoff would seem to be that such collaboration serves to stave off defects. Two minds are almost always better than one, and the odds of catching a defect would seem to greatly improve under constant scrutiny by a second party.
Pair programming would seem to have worth if it costs less than the defects it prevents. This is a tough thing to prove! This proposition is easier to swallow if we believe Barry Boehm's proposition that defects cost significantly more to resolve the later that they are discovered.
A few studies that attempt to prove the value of pairing exist. There's no definitive conclusion. Some studies show dramatic quality improvement, whereas other studies show no significant improvement in software quality. In this article, I'll instead offer a host of reasons why I find pairing beneficial. I'll also talk about some challenges that you may face when pairing.
General Benefits of Pairing
Pairing is primarily a review mechanism. Two sets of eyes help ensure that the code quality remains high. The combined thought of two developers usually results in better solutions and fewer defects. If a team is switching pairs frequently (as I recommended in the last installment), most developers ultimately understand most areas of the system. This knowledge sharing can trigger many benefits, including increased reuse and fewer defects.
As pair switching increases and appropriate refactoring is done, fewer corners of the system are a concern. Inadequate developers aren't left alone to introduce bad code. Very smart developers can't disappear and code clever-but-unmaintainable subsystems.
One often overlooked benefit of pairing is that small pieces of knowledge move through the team. For example, I've learned a number of very useful Eclipse shortcuts as part of my pairing sessions, shortcuts that I would probably not have picked up by myself. The value of such nuggets shouldn't be underestimated. Just one simple new shortcut that saves me 15 seconds can save me five minutes a day if I use that shortcut twenty times.
A pairing team begins to establish an evenly paced, sustainable development rhythm. They begin to produce quality solutions more rapidly than an average team of individual developers. Their knowledge of the system and their tools increases dramatically. Soon, the individual team members have gelled into a true team—one that understands how to work well with one another, and how to recognize and address problems as they arise. This is a direct result of the constant communication team members have with each other through pairing.
With increased coverage through pair switching, a significant portion of risk is eliminated. Management can worry less about dependencies on a valuable resource. If Kathy, the Hibernate expert, abruptly leaves the company, it's no long a devastating impact. Everyone else on the team has at least some knowledge of the persistence code.
The culture of a pairing team changes. Instead of looking for people with specific laundry lists of technologies ("must have Hibernate, Ajax, Spring, and Oracle experience"), a manager looks for developers who work well with others and learn quickly. Of course, the ideal candidate should be willing to pair. An effective interview involves a short session of pairing with team members, which can help answer many questions (although it, like any interview tool, isn't foolproof).
New hires generally come up to speed more rapidly in a pairing environment. Normally, managers give new hires reading materials and some limited access to seasoned team members. After a few weeks, they might be able to be trusted to work a task on their own. In a pairing environment, every is expected to pair, so the new hire is guaranteed an immediate education working an actual deliverable.
I was recently asked how individuals in a pairing team get rewarded. My answer was that any good manager knows who the key players are, because they communicate often with the team. Also, a healthy team will always give credit where it's due.
Pairing offers managers higher visibility into the team. It's pretty hard to hide in the corner and do crummy work. Although it can be painful, I've seen pairing force issues that had festered within a team for a long time out into the open, where the team or management was forced to address the issue.
In a more-advanced pairing environment, additional benefits might ensue. If your organization has two or more teams pairing, it increases the ability for developers to move from team to team. Normally, the reaction of a manager is to resist movement: "I can't afford to lose an experienced developer!" But with pairing, downtime is minimal because new team members can more rapidly come up to speed. Switching pairs between teams also brings increased knowledge sharing and a greater potential for code reuse.
If pairing only provided benefits to management, I wouldn't actively promote it. As a developer who initially resisted pairing, I found pairing to be increasingly enjoyable and valuable the more I did it. I spent fewer hours sitting in review meetings, reading documents, and reading code that I wasn't actively engaged in developing.
My awareness of other parts of the system increased, which helped in my overall ability to benefit the project effort. My résumé skills broadened because I got to code in areas of the system that I would otherwise not be able to touch. Over the years, pairing has helped me learn a new technology far more easily and rapidly than any other mechanism. I've learned new things from even the most junior programmers.
As mentioned in the prior section on management benefits, pairing can allow developers to move around between teams. They can move to groups that offer something they're interested in working on, as opposed to being "stuck" on a specific project.
The most obvious cost of pairing is the resource expenditure. Pairing incurs additional costs, and also raises several issues. I'll touch briefly on a few of these. My contention is that the above benefits more than outweigh the perceived additional resource costs.
Most of the issues raised below can be resolved to some extent with active coaching. Effective pairing rarely happens on its own. A good coach should be available to continually monitor pairing activity in its early stages. The coach looks out for things such as personality conflicts, programmers trying to shirk pairing, and insufficient pair switching. A good coach is able to sit and pair with the developers as "one of them."
Developers with introverted personalities can find that pairing challenges their way of working. More extroverted developers can run roughshod over them. I've experienced this firsthand because I myself am more an introvert than an extrovert. It can take some time to get introverts comfortable with pairing. Sometimes, it's just not for them.
Most senior developers guard their time wisely. They are often impatient with novice developers. However, the opportunity for growing the capability of a team is dramatically improved if the senior developers are expected to pair with everyone else. Initially, it can be frustrating, but junior developers can quickly grow to a point where they add value to a pairing session. My motto is, "Better we grow them now than late in the project."
I suspect that the majority of developers initially resist the idea of pairing. I always recommend a trial period of at least two iterations, each followed with intense retrospection on the practice. Although I don't expect everyone to appreciate or enjoy pairing, I do expect them to give it an honest trial for these two iterations. Afterward, the resisters can convince the team to abandon the practice, or the team can convince them otherwise. Continued resistance or sabotage, once pairing has been accepted by the team, must be eliminated to avoid a project disaster.
Pairing effectively requires cooperation. Often, one half of the pair is flexible enough that it's not an issue. Other times, the pair will need to discuss and figure out how to come to a consensus. Ultimately, it's a question of whether or not pairing will work between the two doing the debating. If neither is willing to budge, it's possibly a lost cause. Don't give up immediately—it does require time to learn how to pair and how to come to agreement. Most of the time, it's worth the effort to find common ground. Sometimes, it's not.
There are certainly more challenges associated with pairing, including accessibility issues, cultural concerns, workstation layout, and lack of "thinking time." A good team will learn to reflect and appropriately adapt their pairing habits. A great team recognizes that these challenges are expected and a part of learning how to work well with one another.
About the Author
Jeff Langr is a veteran software developer with a score and more years of experience. He's authored two books and dozens of published articles on software development, including last year's Agile Java: Crafting Code With Test-Driven Development (Prentice Hall). You can find out more about Jeff at his site, http://langrsoft.com, or you can contact him directly at email@example.com.