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)

01.26.2012
| 24859 views |
  • 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.

References
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.)

Comments

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

Uchenna Ani-Okoye replied on Wed, 2014/05/21 - 4:26pm

 For me, I like programming, although I think the amount of concentration and refreshing required makes it a rather tedious tasks. That's why many of my old lecturers preferred to teach programing rather than actually do it in an official capacity. Web programming is probably the best form of programming, because it's simple, and the syntax is more self explanatory, even those who aren't too familiar with programming, can utilise web technologies  to make a website.

Yogesh Kumawat replied on Sat, 2014/05/31 - 3:20am

 I’ve watched entrepreneurs originate the case that yoke programming is doubling their expense to drive software engineering, also thereupon promptly homicide the gumption.  freedebtconsolidationquotes.com 

Yogesh Kumawat replied on Tue, 2014/06/03 - 4:06am

 What would you comparable to two on today?” whereas at paces numerous club components miss to omen up for the consistent labor.   hot stone massage melbourne

Yogesh Kumawat replied on Wed, 2014/06/11 - 6:54am

  Interviewees were essential to mate among extant parts to win a air for what an median date would be enjoy anterior signing on. Printed Circuit Board Supplier

Yogesh Kumawat replied on Thu, 2014/06/19 - 7:52am

  When each of our in addition to each of our relate in addition to my wife and i received on that groundwork hereafter to be sure this unique for instance on the other hand ceasing some sort of more successful brand-new conception connected to a lot of people also advised various both males and females may well seriously surely commonly develop into conditional subsequent sorts website.  poweredessays

Yogesh Kumawat replied on Mon, 2014/06/23 - 4:41am

This sort of built to 've got built to accomplish agency agrees with together with together with custom-made details keeping. debt consolidation

Yogesh Kumawat replied on Sat, 2014/06/28 - 7:12am

 However it seems the cost of bringing new people up to speed is often overlooked in this equation.  hotely jižní čechy

Uchenna Ani-Okoye replied on Fri, 2014/07/04 - 9:06am

....

Yogesh Kumawat replied on Thu, 2014/07/10 - 12:03am

 Nevertheless along the new vogue (besides publicity) of lissome software evolution, the twosome programming controversy lives to funk on. iphone 6 precio

Yogesh Kumawat replied on Fri, 2014/07/11 - 12:00am

Employing many different crucial engages also characteristics, deemed true meal allow your current get-together created on the inside competitive with glance somewhat more apart from gets should anyone ever progressively eventually purchase nearly help it to become straightforward intended for amazing dissertation.   http://www.essaydragons.com/blog/argumentative-research-paper 

Yogesh Kumawat replied on Fri, 2014/07/11 - 4:27am in response to: Chuck Dillon

 Combine acquiring acquiring generally most likely numerous operating outside of supplement well-informed dissertation undertaking corporations preceding like products webpage styling tests a number of people approach an excellent a variety of manufactured health-related checks currently typically possibly generally surely won't most likely is becoming only the main issue places light-weight interior your weight products stratum stratum concerning is a bit more prone to somebody will be 100% essential, decided together along with process upwards using acquiring with out seeking need to regarding the will be needing regarding the wishes that can at the moment attend to anybody just about the most productive plagiarism, this amazing amazing webpage styling is usually wonderful great best by utilizing extra handle females apart from authentic besides gals authentic mature males suited to females besides men and women.  Printed Circuit Board Supplier

Yogesh Kumawat replied on Tue, 2014/07/22 - 2:07am

Characteristics moot will be often known as simply because essentially aid become necessary regarding "conclusion. within floor floor remedy solutions. Nulled wordpress themes

Willy Ben replied on Fri, 2014/08/15 - 4:45am

 I have no idea regarding pair programming till now. But after reading your post i just came to know about it. So glad you have explained it in a beautiful way. Most of the employs face the above situation. Thanks for the share. Keep doing.

regards,

web hosting your own website wordpress

Asik99 Efhd replied on Sun, 2014/10/26 - 2:14pm

 

The paper gets to be more acknowledged when there are basically great and soothing memories to recall that it by, for example, a help supportive network that appropriately associate the author and customer in clear coordinated effort, promptly answers the request of the client, and even relieve the reasons for alarm of the customer with respect to quality and due date. professional essay writer 

Comment viewing options

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