“Are you pair programming?” our manager asked in his snarky tone, while using exaggerated double air quotes to emphasize his skepticism. He then walked away without waiting for a response…

This is merely one example of numerous instances I’ve experienced over the years from skeptics of pair programming.

This isn’t a particularly new concept, and in the past both hardware and software developers worked in pairs on a routine basis. However with the recent popularity (and notoriety) of agile software development, the pair programming debate continues to rage on.

Why does this practice evoke such an emotional response from people?

Pairing fatigue

Pairing fatigue seems to be one of the more common arguments against pair programming. In fact, one conversation I had recently was with an individual who paired for over 6 hours straight and then never paired again. His face scrunched up when speaking about it, so much so that I think he felt actual pain even thinking of it. I inquired as to why he didn’t take breaks, or use the pomodoro technique but he was not willing to divulge the details.

Note: It is important to work at a sustainable pace and to take small, but frequent breaks. This also applies to pair programming!

Single points of failure

One of my favorite quotes from a past employer is “We are not a single threaded organization”. Boy was he wrong, we had single points of failure everywhere! Unfortunately pair programming was viewed with such disdain that it didn’t survive pilot mode. At other organizations I’ve seen people pair and share knowledge in such a way that the single threaded organization remark actually held water. People could step into the code successfully instead of calling a software engineer while he’s on vacation at Disney World with his family. (true story)

Note: It is important to have a shared knowledge of the code base, otherwise your organization may not recover when key team members leave (and they will).

It is too expensive to have 2 people at 1 computer

Another argument against pair programming is that it is far too costly to have two developers work together at the same time. I’ve watched executives make the case that pair programming is doubling their cost to operate software engineering, and then promptly killing the initiative. However it seems the cost of bringing new people up to speed is often overlooked in this equation.

Note: When attempting to realize the cost/benefit analysis of pair programming, contrast the amount of time a new hire takes to get up to speed on his own versus when pairing with an existing team member.

To help visualize this argument I’m making, imagine a pair programming slider.

Pair Programming Slider:
0% []————————————–[] 100%

On the left at 0%, your team members have absolutely no idea what each other is working on within the code base.

On the right at 100%, your team members emphatically hate one another.

Neither extreme fosters team growth, so as with most practices you’ll need to strive to find the correct balance for your team and organization.

Yeah, yeah… give me real world examples

A year ago our development team practiced pair programming at least 4 or more hours of our 8 hour work day. Envision the paring slider at or over 50% every day. This was mostly because we had existing team members with a great deal of domain knowledge transitioning off and new team members transitioning in. And before you ask, yes we did our best to screen the new team members during the interview process. Interviewees were required to pair with existing members to get a feel for what an average day would be like before signing on.

It is now a year later, and we are currently pairing at roughly 25% for 3 days a week, and 45% for 2 days a week. We’ve revisited how we pair at each and every iteration retrospective (2 weeks). This is important because we need to talk openly about how we are working together as a team and adjust things as needed.

We’ve learned a great deal about each other and how we work over this past year.

I’ve found that when we dial back the slider and pair for fewer hours that we tend to communicate less with each other. The team room buzz is reduced significantly during these times, and it is more difficult to keep a pulse on the team as a whole.

I’ve found that having rotating pairing schedules as an artifact of our daily stand up helps keep us honest. We now even ask the question “What would you like to pair on today?” since at times multiple team members want to sign up for the same task.

I’m quite certain we’ll continue to learn over the next year as well.

So in short, before you declare your undying hatred for pair programming, try giving it another shot with some well thought out checks and balances. It just may surprise you.