Pair-programming techniques -- introduced as an Extreme Programming, or XP, practice in which two developers work...
together using one machine -- have been shown to provide improved communication and quality of code. This idea has been adapted in pairing developers and testers, business analysts and testers, two coaches or any two people who require strong communication and collaboration.
In this two-part series, we'll be talking first to Kim Barnes, a senior software engineer at Denver-based GoSpotCheck Inc., about her user experiences with pair programming in its purist sense. In the next tip on pair-programming techniques, we'll hear from Brett Palmer about his experience with adapting the power of pairing for coaching and beyond.
What do developers think?
Though my background is in software development, I must admit: Any pairing I've done has certainly not followed the XP purist's rule of "two developers, one machine." In fact, when I learned about this technique, my initial thought was, "I bet developers hate that." But when I later heard veteran software developer Kim Barnes say she would only work at a company where pair-programming techniques are practiced, I took the opportunity to dig deeper.
Barnes' early experiences were mixed. In the early 2000s, while working at Sun Microsystems -- now Oracle -- Barnes tried pair programming for the first time. "I saw a glimpse of what it was like to learn directly from someone by pairing. It was kind of a hold-onto-your-seat session in which I barely kept up mentally, and it was remote, but it blew me away." She described her early second experience as terrible. "Our attempt at pairing failed miserably, and it turned into two developers going off on their own and coming back together to code review."
Years later, Barnes had the opportunity to pair daily, and it's now a practice she thoroughly enjoys. Admitting it's not for everyone, she said she feels that for her, it's the best way to learn, teach, communicate and collaborate with her teammates. Her team rotates, so each teammate gets to work with everyone. Barnes said there is much less blame and strong team accountability with this approach. "The team bonding is amazing," she said. Another benefit to pair-programming techniques Barnes pointed out is that a whole team becomes familiar with an entire codebase, so there are no bottlenecks or dependencies on a sole developer who is an expert in a particular piece of a code.
What about customization of machines?
One part of pair programming I felt might be frustrating is its inability to customize or personalize a machine to account for your own preferences. Barnes practiced pair programming both in its purist sense of having only one machine assigned to a pair, as well as in an environment where developers have their own computers and a pair chooses which computer to work with for that particular day.
When machines are assigned to a pair, rather than to an individual, they are set up identically, allowing pairs to easily use any machine, Barnes said. "Many of our tools are modified to use as a pair instead of an individual. For example, commits are made with an author set as a combination of two people, not a single individual," she said.
On the other hand, when team members have individual computers, they have the advantage of customizing, perhaps sharing a tool or technique their partners might learn. However, there's a downside to this approach. "As individual computers, the development-environment setups diverge, and it can cause some inefficiency for the non-owner developer to use the other developer's computer easily."
No matter which approach is used, Barnes said, they set up two monitors, two keyboards and two mice to a pairing machine, so each person will be able to take control, as desired.
Advantages and disadvantages
One issue developers may have when they try a pair-programming technique is to figure out the best way to work together. Barnes described a couple of different paradigms that can be used. "The driver [or] navigator model has one person typing, while the other is giving high-level directions. The two should switch roles often. Ping-pong pairing is a good fit for test-driven development, where one person writes a failing test, the next implements it and then writes a failing test for the first person."
Barnes said the key is not how to share a computer, but how to best communicate effectively with one another. "If the pair can come up with a plan and jointly navigate it, course-correcting as they go, then the mechanics of sharing a computer become a nonissue." Barnes said she believes it takes about three months of daily pairing for developers who are new to this practice to feel acclimated.
Though pairing has been criticized as an expensive practice due to the fact that two developers are needed rather than one to develop a segment of a code, studies have shown the quality of a code improves dramatically when this approach is used. Barnes confirmed from her experience that code quality has been much higher when pairing was used. And she added that a quality-assurance team, recognizing the higher quality of a code, insists on implementing pair-programming techniques.
Pair programming can take some time to get used to, but Barnes is sold on its practice.
"Working together on one machine allows a pair to stay focused on one task and work most effectively together. The increased focus results in higher-quality work, fewer distractions and, usually, a more enjoyable workday."
Tools for side-by-side collaboration
Collaborative software development: Can't we all just get along?
Taking pair programming to the next level