Agile Zone is brought to you in partnership with:

David has enjoyed success using agile and lean techniques at several companies near Washington DC and San Francisco. He joined his first startup in 1999, and helped scale it to a 13 million dollar acquisition in 2006. He now brings entrepreneurial thinking into large organizations so that disruptive innovation can emerge. David is a DZone MVB and is not an employee of DZone and has posted 30 posts at DZone. You can read more from them at their website. View Full User Profile

Top DZone Article of 2011: I Hate Pair Programming (and your code and you)

  • submit to reddit

“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.

Published at DZone with permission of David Bland, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Chuck Dillon replied on Thu, 2012/01/26 - 3:06pm

I'll readily admit I'm a PP skeptic and no I've never done it per se.  Like it or not I get a visceral negative reaction to the idea.  The practice is not compatable with my personality and how I work.  I don't say that blindly, I've had personality profiles and they consistently confirm what I know - I'm highly analytical and do not function at all well in a dynamic situation.   So for PP would be imposing a work environment that would not be acceptable.  Bare in mind that I'm not meticulous when I design and develop software. I've never been in a department where I wasn't the most productive developer.

I'm not saying PP is bogus for everybody.  I'm saying it's not for everybody.  What's unfortunate is that most of what I've read about PP disregards that fact and implies what's good for the author is good for everybody and if that's not right there must be something wrong elsewhere than the PP application.

My responses to your points...

Fatigue - I would guess that the individual was hating the excerise and didn't take breaks so that he could get it over with ASAP.   I would also guess he didn't elaborate because he didn't want to get into a religious argument about it.

Stepping into the code without calling - IMHO this is and always will be a bogus argument.  Firstly, what is needed is institutional knowledge not shared knowledge of a team that may all be gone in short order.  Secondly any developer who understands the problem space and has the requisite skills should be expected to pick up the code/designs of others efficiently without needing their hand held.  If Joe Programmer says he can't do the job without talking to Bill you need to retask the job to someone who has sufficient skills to work the problem.

Contrasting spin-up time to the cost of PP - Apples and oranges unless you only apply PP as part of the new-developer-orientation program and that would be a choice not a necessity.  An organization can spin a developer up efficiently outside of active development then turn him/her loose.  The previous comments also apply here.

The slider - This is a false premise.  It's inaccurate to suggest PP is necessary for the team to communicate efficiently.  It's inaccuate to suggest that people who can't work effectively under PP have hate issues.  See my comments on fatigue above.

Real example - When I was in my twenties I was in a softball game on a very foggy night.  We were playing the pot-head team, it was the 70's and they were heavy pot users.  Those guys had no issue with the fog.  We couldn't find fly balls, they didn't miss one.   The point is: do what works for your team.  Nobody is saying PP can't work but you seem to be suggesting it can work for anybody.  That's simply not supportable.


Mark Unknown replied on Fri, 2012/01/27 - 10:20am in response to: Chuck Dillon

While I am not saying this is a case for PP... "Secondly any developer who understands the problem space and has the requisite skills should be expected to pick up the code/designs of others efficiently without needing their hand held. " This is not true. While i can pick up code and NOT understand the problem space ( I have done it over and over), it is very difficult to pick up poorly designed/coded/architect-ed code. Given enough time and space, I probably could work it out (and I have). It is easier to talk to "Bill" and sometimes necessary. And then again, sometimes useless. I have done code reviews where they don't know why they did something or what it does.

Chuck Dillon replied on Fri, 2012/01/27 - 2:46pm in response to: Mark Unknown

I'm not sure we are disageeing here.   I didn't mean to suggest that one should avoid consulting with any authors that are available.  Sure if they are available it will normally be worthwhile to consult with them.

I'm saying it's not unreasonable to expect an appropriately equiped engineer to pick up where others left off even if they aren't available.  My main point is that IMO the asserted advantage of mind-melding via PP is overblown.

Paul Russel replied on Sun, 2012/06/10 - 7:58am

I really like the idea of pairing % of the day. This makes a bunch of sense. Often we think of pairing as a 8 hour thing every day. But moving slowly into the idea and retrospecting what is working and what is not is a great way to go.

Great points here

Kookee Gacho replied on Mon, 2012/06/11 - 10:32pm

There were several entries in the D!ZONE series, each one containing an increasing number of files. These included D!ZONE, D!ZONE 150, D!ZONE 2, D!ZONE 3 and D!ZONE Gold.- Dr. Paul Perito

David Bland replied on Thu, 2012/06/28 - 2:42pm in response to: Chuck Dillon

I find it interesting that you begin with saying you've never tried it and then conclude with a softball game with pot heads.

I'm not mandating pairing, but I do suggest it to the organizations that I coach.

It doesn't resonate with everyone. 

Carla Brian replied on Fri, 2012/06/29 - 7:22pm

This makes sense. I hope to have a big process as well. Good job on this. - Mercy Ministries

Yogesh Kumawat replied on Mon, 2014/03/31 - 3:05am

 Pairing bore appears to be digit of the better everyday defenses touching duo programming. In circumstance, alone talk I had recently was along an one who double for ended 6 hours directly besides thereupon never double afresh.    Click Here

Yogesh Kumawat replied on Mon, 2014/03/31 - 7:58am

 This isn’t a particularly pristine opinion, besides in the after both hardware furthermore software developers worked in braces on a procedure basis. Nevertheless accompanying the late vogue (further fame) of nimble software evolution, the brace programming parley stays to madness on.  essay writer service

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.