Agile Zone is brought to you in partnership with:

Mendelt has posted 1 posts at DZone. View Full User Profile

The dirty secret of pair programming

01.12.2010
| 5540 views |
  • submit to reddit
Pair programming is one of the more controversial extreme programming practices. Having two people work on the same piece of code at the same time looks very unpractical and inefficient to someone not familiar with this practice. Pair programming proponents like me are usually quick to point out the benefits like improved quality, less rework, better communication and better knowledge sharing within teams but I think the biggest reason pair programming works is usually kept quiet.

People work harder when there is someone looking over their shoulder.

I'm going to be completely honest with you here. When I work alone I spend a considerable amount of time surfing the web, reading email, twittering (you can follow me at @mendelt) getting coffee and talking to coworkers. This means I'm spending less time working but it also means I'm constantly interrupting myself during the time I am doing work making me even less productive.

Now we don't tell our managers this because it wouldn't do anyone much good, the problem is a bit more complex than just people slacking off. What I've observed is most people have a hard time pacing themselves. We do really focused work for five minutes and then take a break. Unfortunately breaks have a habit of taking more time than they should and productivity goes out the window.

To solve this problem we need a way to maintain a sustainable pace. Pair programming is a way to do just this. Forcing yourself to explain what you do to your pair is a great way to maintain a sustainable pace and work a bit harder.

Published at DZone with permission of its author, Mendelt Siebenga.

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

Tags:

Comments

Dave Rooney replied on Wed, 2010/01/13 - 1:00pm

I talked about this just last night!  There is a concept that goes hand-in-hand with pairing, called Core Hours.  The team works on the project, and nothing but the project, from 9AM to 3PM for example (with time for lunch).  During those hours, there are no distractions - no surfing, no Twitter, no e-mail, no phones.  All of those things can be taken care of in the other 2.5 hours of the day, as well as the usual corporate administrivia you deal with.

The idea is that, even if you aren't pairing, you will be more productive when you can focus on your work for 5 hour than if you are distracted for 8.  Pairing adds the "peer pressure" factor, but implementing Core Hours eliminates the "dirty little secret" aspect.

Dave Rooney

The Agile Consortium

Al Iago replied on Mon, 2010/01/18 - 4:09pm

I've found pair programming to be most useful under several conditions:

1) You spent last night drinking, and are not able to function.  Just make sure you're not the person at the keyboard, do your best not to fall asleep, and throw in a comment about indentation every 10 minutes.

2) You're one of those untrained managers who needs to breathe down people's necks, because you don't trust your employees. The benefit here is that someone else is doing the breathing for you, and you can claim that you're cool at the same time.

3) You're stuck with someone who is a terrible programmer, and usually does more harm than good.  Just pair them up with a good engineer, and make sure the good one is driving. You're paying the lousy programmer to do nothing, but it's probably worth the cost.

4) You need to hide the fact that you're not having very productive month. When your manager says, "this team generates about half as much as it should," you've got your answer: pair programming!

Comment viewing options

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