Pair Programming Gets Mainstream Coverage, Lukewarm Response

The Wall Street Journal has begun to take notice of the growing number of technology companies that have been practicing Pair Programming and has published their take on the practice in an article titled Computer Programmers Learn Tough Lesson in Sharing.

Pairing is finding fans at technology companies including Facebook Inc. and mobile payments start-up Square. Its advocates speak in glowing terms of the power of coupling, saying paired coders can catch costly software errors and are less likely to waste time surfing the Web.

However, they were quick to find issues with the practice, comparing it with dating.

The reality can be more like an endless bad blind date. Annoyances that plague partners everywhere can quickly pile up: from poor personal hygiene and table manners, to feet on shared desks and loud chewing.

Pivotal Labs, a software-development shop that was bought by technology giant EMC Corp. in March, has its 175 engineers pair all day, every day. Some play the field, changing partners daily in a practice called "promiscuous pairing."

The dating metaphor continues,

Working out problems with a pairing partner can be a lot like working out problems with a significant other.

"It's like any relationship," Ms. Kite said. "If you don't talk about the problems, it's not going to work."

The article closes with the story of Drive Current and their experience with pair programming.

After two years of asking the company's engineers to spend three hours a day pairing, Mr. Kocol phased out the practice in September.

"I don't think anyone misses it tremendously," Mr. St. John said.

Several developers weighed in with their opinions and experiences on pairing in the comments. Anne Bennet, had this to say.

It sounds awful. We had a manager who was talking about it. Fortunately he has left. Thank goodness I'm nearly retired. I can see having another person review code, but co-writing? Not for me.

Mike Edwards had some positive experiences with pairing.

My experience is that pairwise programming benefits those who must work within the bowels of an inherited codebase that has been long neglected and is in disrepair. Having a witness somehow makes it more tolerable.

Christopher Wong felt it came down to your personality type.

I find pair programming to be like being stuck in a meeting all day, every day. I find it exhausting and would burn out. But there are people who will be energized by this arrangement. It's likely a question of personality types, and should be left to the discretion of the practitioners.

Catherine Jefferson could see the benefits, but wasn't convinced it was for her.

If I force myself to quit hyperventilating and think about it, I can conceive of people and types of programming where this might work. But if I were expected to do anything remotely resembling this on the job, I'd burn out in a day or less. SHUDDER

Thomas Gordon considered it a fad.

Wow this is funny. Fads in programming. And I was just starting to worry about the scrum and now someone has to sit in my lap. I personally am surprised this shared desk works. I find most programmers to be really in love with their own ideas and really surprised that anyone would consider doing anything differently than the first way that came to their minds to solve the problem.

Not everyone agreed with the Wall Street Journal assessment. Roger Neel, co-founder and CTO of Mavenlink, felt the article gave an unfair portrayal of pairing. In his view, The WSJ Got it Wrong On Pair Programming.

We decided early on to use Ruby on Rails​ and started looking for an early-stage development partner. We found Pivotal Labs. During our project's scoping (hi Davis and Rajan!), we talked about Pivotal’s general agile practices, XP, test-driving, and pairing. For us, at the time, pairing was a great way to get me trained up on their best practices. Little did I know that we'd spend the next 3 years working there and would hire our own team based on pair-programming acuity.

Roger took issue with examples the WSJ chose.

Thanks for giving us one example of a company whose culture didn’t like pairing and an example of some guy who didn't like it. What about all of the other companies and people who do?

He explained the benefits of pairing and drew a comparison between pairing and Yoga. Explaining how both were originally looked at as weird, and how Yoga has become a mainstream activity.

Pairing is about collaboration, writing better code, teaching, and keeping each other in check. With some practice, collaboration and bouncing ideas around comes more easily, but not everyone is going to grunt 'n' code, as Kent Beck mentioned. You don't stop doing Yoga because your hamstrings are still tight and you don't stop pairing because you need to talk a little bit (or a lot).

Roger also felt that pairing had other benefits.

Pair programming and daily pair rotations help reduce the need for [many meetings]. If we all frequently cycle through much of the product, everyone has experience with the business’s parallel development tracks and every pair is able to make their own decisions around the day’s work.

While acknowledging pairing is not for everyone, Roger also compared pairing to other common practices.

One traditional model is to build software separately, doing regular peer code reviews, and coaching each other. This can work well when an organization is extremely disciplined, but what often happens in reality is that every developer has 16 hours of code to write in an 8 hour day, so the last thing that they're thinking about is someone else's problem. Also, without context or a large time investment, how am I supposed to get my head around a problem that someone else has been working on for days? Time-strapped reviews often lead to surface-level re-factorings, but not to deep discussions and improvements.

By combining agile design techniques with constant communication and rotations, pair programming is a great way to iteratively come to consensus, rather than “throwing the cards in the air” and starting over after something is half built.

What has your experience been with pairing? If you're a fan, how have you presented the idea to those who are not as familiar with the practice?

Note: You can also check out our our survey results on pair programming adoption or take the survey yourself.