Pair Programming Is Still Vibrant

Pair programming research pioneer Laurie Williams, a professor of computer science at North Carolina State University in Raleigh, NC, has not published a study about the practice since 2011.

Williams, co-author (with Robert R. Kessler) of "Pair Programming Illuminated," a foundational text of the agile methodology (which features two developers working on the same code simultaneously, one as the "driver" actually typing in code and the other as the "navigator" calling out instructions and reviewing the code), said the pair method has not caught on as widely as she hoped it would when she began publishing about in 2000.

Williams, who still does presentations about pair programming, said one of the reasons she stopped publishing research on the practice was that so many of the questions she received had switched from developmental metrics to "questions that were in sociology, psychology, and cognitive science, like ‘What’s going on with the brains when people work together?’"

Such questions were interesting, she said, but not quite aligned with her main research interests. However, such factors, whether project leaders are trying to quantify them or not, are becoming centerpiece issues in evaluating where and when best to employ pairing.

A Serendipitous Discovery

Walter Guevara, a Los Angeles-based software developer who writes about programming as ThatSoftwareDude, was introduced to pair programming as the result of a malfunctioning computer. "My computer had a virus or something," Guevara recalled. "It was super-slow and we had a deadline, so I jumped on the computer of the person next to me. It started off kind of rough because it was new to both of us, but within the day it felt very natural to be calling out commands eight hours straight and typing. We got it done. We met the deadline, and it was cool to program that way."

In a blog post about the experience, Guevara outlined the positive and negative about his foray into pairing. He said he would be open to implementing it again, as either a programmer or a project manager, but he did not think his manager would champion it. "After a while, I think he felt a little weird we were still pair programming. He said something like, ‘Isn’t your computer fixed yet?’ I think that’s the norm, that’s how most managers perceive it. After we were done, it was kind of like ‘okay, you did good, let’s move on.’ I didn’t get the feeling we were going to try it again."

Ingrained in the culture

At the other end of the spectrum from Guevara’s ad hoc and temporary experience, Chicago-based global software consultancy ThoughtWorks, employing more than 3,000 people in 34 offices worldwide, uses pair programming as its "default" programming method, according to ThoughtWorks technologists Neal Ford and Scott Shaw.

Ford said he "kind of reverse-engineered" why pair programming was so effective, and distilled his findings into a left brain-right brain metaphor. "The left brain is really detail-focused, on things like single lines of code and getting syntax right and so on, whereas the right brain is very pattern-matching, very holistic, and in the world of design patterns. Your brain can’t work in both modes at the same time. So why and where pair programming is so incredibly effective is, it’s the only way to get one full brain focused on the problem by utilizing two half brains at a time. The person doing the typing is very much in their left brain, and the person doing the navigating is very much in their right brain. That is why, at the end of the day, I think it works so well."

In terms of comparing the productivity metrics of pair programming vs. solitary methods, Ford said, "the root of the problem is how do you measure developer productivity, which we have no idea how to do. …In the early days we used to get so many questions about pair programming as part of our process. We almost never get questions about it now; it’s just an accepted part of what we do."

Ford said ThoughtWorks uses "the metric most companies recognize the most; when we do a flat-rate project, we pair-program because we are convinced it produces higher-quality code. We put our money where our mouth is."

Shaw said continuous improvement practices are part of the company culture, and in regularly looking at what has worked and what has not, developer teams would be more careful about pair programming more often. "It’s easy to slip out of the habit, to do things expediently and not pair," Shaw said, "but they never say, ‘We should stop pairing.’ Teams always judge their own performance, their own productivity, as being better with pairing."

Empirical evaluation

Senior executives at Warsaw, Poland-based software development house EL Passion were so curious about pair programming, they recently ran a formalized two-week experiment comparing teams using pairing and solo methodologies.

The company’s chief technology officer, Karol Sarnacki, said the experiment yielded unexpected insights, positive and negative, about the methodology.

"Before the experiment, I thought pair programming was a cool buzzword, something easy to try and implement," Sarnacki said. "After all, it’s just sitting one person beside another one, and telling them to work together! Now I know that it’s not that simple, and that it is actually hard work to manage a paired team."

EL Passion will not be enforcing company-wide pair programming, Sarnacki said, and he does not think the experiment was the best way to show its value. However, he said, it had many positive effects in the company, including:

• Provoking discussions inside the company. People learned a lot about pair programming, its advantages and limitations, and proper methods of implementing it.
• It encouraged more teams to try pair programming.
• It demonstrated neither pair-programming proponents (who said pair programming would always boost productivity) nor opponents (who said it was a waste of resources) were entirely correct.

While the experiment was long over, Sarnacki said, "the influencers stayed with us, and they are already changing the way the teams work, from inside," he said. "And I’m not going to stop them."

Gregory Goth is an Oakville, CT-based writer who specializes in science and technology.