Saturday, November 24, 2007

Pair Programming Redux

I've been working for a few years in a mostly XP pair programming environment. Here's my list of pros and cons of pair programming based on this experience:

  • Unlike most other projects I've worked on, I've seen an overall improvement in the code quality over the past few years. I've never seen that happen on any other project. As people learn better ways of doing things, pairing helps to disseminate that knowledge in a way that meetings, presentations, and code reviews just don't.
  • In my experience, there hasn't been a problem with people who are working together arguing and consequently getting nothing done. On the contrary, pairing seems to have encouraged an atmosphere of cooperation and friendliness.
  • Sometimes under time pressure one can't resist the urge to copy and paste some code or hack in some functionality without developing tests first. The mutual supervision of pair programming really does seem to have a positive effect on these kinds of transgressions. It's a lot harder to take a nasty shortcut under the watchful eye of the person you're pairing with.
  • I would tend to agree with the principle that working in pairs doesn't really hurt overall productivity. The reason seems to be that the team having a common understanding of the code and the business generally trumps the value of having two people typing code in separately. Integration is the real difficulty in many software projects, so whatever gain in the amount of code written might come from separating pairs, that gain seems to be offset by the greater consistency of code written when pairing.
  • Hygiene: Pair programming in our environment means sharing one keyboard and mouse, and sitting in close proximity to another person all day long as well as switching pairs frequently. We often have had problems with people spreading colds around the office. I think developers in an XP shop should have their own personal wireless mouse/keyboard combination as well as their own chair that they don't have to share with anyone else.
  • Ergonomics: The reality is that sitting at a computer is not a natural position for the body and you can do damage to your back, neck, shoulders and head, and of course your wrists over time. Pairing tends to encourage bad ergonomic habits, because it's inconvenient to change the position of the keyboard tray, monitor, chair, etc when it's time to take one's turn at the keyboard. I really believe that these things need to be considered if you want to do pair programming long term.
  • Personal space: Some people enjoy having some peace and quiet as well as a space where they can keep their things. As much as I am a fan of pair programming, I think developers should have their own desks away from the common bull pen they can retreat to from time to time.
My conclusion is that pair programming does work, but it requires some care. First, developers have to respect each other and be willing to compromise. Also, pair programming 100% of the time doesn't work. Sometimes when facing a design problem it helps to go off and work separately, then get back together and discuss later. Also, pair programming - constantly communicating, asking questions, explaining and justifying one's own ideas throughout the day - is very demanding. After a period of time, burnout can occur. When that happens, I think it's a good idea for people to be able to work on something alone for a while.


Anonymous said...

I personally can't cope with pairing with that setup for more then a few days.

Keyboards and mice are so inexpensive as to be practically free. Not having to push the keyboard back and forth makes for much faster interaction.

Even if you have to purchase the second monitor yourself, its worth it for your own comfort.

I've never met anyone who after pairing on a full dual setup, preferred sharing.

Agile Jedi said...

I am glad to see someone stressing the Ergonomics of Pair Programming....if the setup is wrong pairing can become very painful!

read me @

Anonymous said...

Burnout... oh yes.

I never did like programming much mind you, but XP resurrected it for me for a time via PP.

The problem I have with PP is that I believe programming is essentially about design. Design is often difficult to communicate and is also highly personal. Some people can 'see' good design, others struggle. Often two people can both see an equally good but differing design.

Its exhausting debating it and its particularly tiresome if you're working with the kind of person who is a bit 'thin skinned'. I find that there are a great many people who take offense if you don't agree.

Its also difficult if you disagree about XP itself. I believe that simplest is best. I will prefer less efficient code if its more readable. Others disagree.

Its also difficult if you have a different set of values. For example I'm very keen on refactoring. I like simple code with little conditional logic and I like to spend a lot of time refining what I've just written. Others are more focussed on the 'new code' dimension and this causes conflict.

Sometimes I just like to do it myself. I know its not rational and I know its sub-optimal, but sometimes its just more fun that way.
Pairing works when two personalities fit. It struggles when they don't.

Vladimir Levin said...

Hello Anonymous...

> I never did like programming
> much mind you

Heh, you seem to know a fair bit about it considering! :)

As for the differences between people doing pair programming, like I said, it has neither been a problem on my current project, nor on another XP team I worked with prior to that. That's about 4 years and 40 people. Everyone's mileage may vary, of course.

I do think if you have people on the team who have very different points of view, pairing is probably *not* a bad idea. As they pair, they will actually learn from each other and become more comfortable with each other's code. Otherwise, each person's code will be a silo which the other person won't touch. It may be a bit painful at first, but managed properly, I think pairing could ultimately be a good thing for this kind of situation.

Dave Nicolette said...

Maybe both the ergonomic and hygiene issues could be addressed if each team member had their own keyboard and mouse. Two birds with one stone.

WRT going off on your own to do design, what about you and your partner retiring to a semiprivate space to work through a design issue? Who says design has to be done by one person working alone? Why would that be better than collaboration?

I'm not so sure design is really all that "personal". For OO development, most people generally follow certain well-known principles that have resulted from the experiences of thousands of developers. For specific technology stacks, there are usually some more-or-less standard architectures or frameworks. I guess this depends on the domain, too. Some domains may not lend themselves to "standard" design approaches.

Dave Nicolette said...

Nice summary, Vladimir. I would add something to the "cons" - ambient temperature. Sometimes there will be a person on a team who feels too cold all day while a team mate feels too warm all day. Doesn't happen often, but when it does it can make the work environment unpleasant for certain team members.

Regarding the need for private space, you might enjoy the book Peopleware by Tom DeMarco and Timothy Lister. They propose a layout for collaborative work spaces that includes a group work area for collaboration (such as pair programming, for instance), semiprivate areas for brainstorming, thinking, or research; and private areas for phone calls, checking email, and having one-on-one discussions. A team needs all three types of space to function comfortably.