BT

Pair Programming Gets Mainstream Coverage, Lukewarm Response

by Todd Charron on Sep 09, 2012 |

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. 

 

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

The WSJ article misses the point by Woody Zuill

Pair programming is about effectively writing software. It takes some practice just like anything else we need to learn. The article itself and a number of its comments describe bad experiences with pairing. I'm sure the commenters are sincere, yet what they are describing seems more about a failure of humans to be able to work well with each other, and less about pair programming. It just happened that the pair programming experience is how they exposed the inability to work together.

If all of your experience with programming has been solo, there are some things you'll probably need to learn before you become good doing pair-programming. It is similar to playing doubles tennis if all you have done is singles. The rules are a little different, and you have to learn to work with a partner. Once you iron things out it can be a lot of fun, and with pair-programming I've found it to be a great deal more effective and productive.

My experience with Pair-Programming is very positive. I've been using this practice since I first learned about it around 1999 or so. In many places I've worked there has been no opportunity to pair, but I've constantly used Pair-Programming whenever possible. Many of the dysfunctions described in the WSJ article (and its comments) can be easily overcome by following reasonable protocols for human interaction. The remaining dysfunctions can be resolved by regularly reflecting on the practice, then tuning and adjusting to improve things.

Where I am currently working we use a practice we call Mob Programming, which can be considered a "Whole Team Approach". We all sit at the same computer and use dual projectors as dual monitors to project the screens onto the wall. There are typically 5 or 6 of us working at the same time, in the same space (16ft x 18ft area), on the same computer, and solving the same problem. We've been doing this every day for over 14 months and have found it highly productive. Obviously, it is not for everyone - but it has worked well for us. It's not quite as simple as I describe it here, but hopefully I am clear enough that you can get the basic idea.

Here is a link to a time-lapse video we made of a full day of work using this on YouTube so you can see this in action as we currently do it: youtu.be/p_pvslS4gEI

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

1 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT