WhatPreventsPeopleFromConsideringPairing

During my teaching and speaking in Israel, I discussed pair programming. Several people were incredulous. They could not imagine that pairing would be useful, would be more productive than solo work, nor could they imagine how to write performance evaluations or give raises.

I had some suggestions for each of the issues, but I'm not sure they heard me :-) What is it about pair programming (or pair writing or pair anything) that sets people up for such polar views? -- JohannaRothman 2005.03.26

When I first started working, I loved programming with other people. It made my stuff better. Management vehemently objected to people working together. They believed that the amount of work that could be done was a multiple of the number of people working on the project. Each time more than one person worked on something, it reduced the multiple.

I suspect that this view is still pervasive. And on the surface it makes sense. But scratch a little and you will find other variables, such as the quality of interaction, that influence the output of the system more than the number of people.

SteveSmith 2005.03.26

Steve: They believed that the amount of work that could be done was a multiple of the number of people working on the project.

They also believe in 100% utilization, nothing will go wrong, and the workers are fungible. DonGray 2005.03.26

Most programmers are unaware of how much time they *are* pairing: collaborating on setting up the IDE and SCM or some other system configuation, pair-debugging, working together to understand requirements or obscure code. They also don't realize that pair-programming is a *lot* more enjoyable and productive than pair-debugging.

Because it's only appropriate in the programmer-culture to pair-debug when solo debugging has failed, agreeing to pair program is to "admit" that solo programming is "too hard". This is a "macho" ethic, of course.

KeithRay 2005.03.26

If they're basketball fans, have them notice what happens when a good team panics and starts playing as 5 individuals. I saw that twice today when one team lost a 20-point lead and another lost a 15-point lead with only four minutes to play. - JerryWeinberg 2005.03.26

Johanna, Were there any signs among the incredulous that anyone was mulling the possibilities of pair-programmers? That is, trying to imagine what it might be like?

After my first AYE, in 2001, and meeting Keith Ray as my first live "Pair Programmer", I talked about it with a fellow employee. She was also incredulous and said it was a crazy idea. Note however, she and three other systems programmers had intentionally, with management approval, set up a quad open cubicle so they could communicate more easily. Knowing her, I think she was mainly creeped out by the idea of someone "looking over her shoulder" all the time.

MikeMelendez 2005.03.28

At one client recently, the team told me that they'd been pairing for quite a while and liked it on the whole. One of them did pipe up on the third day that I was there to share something that was bothering her - sometimes after an entire morning of sitting behind her pair and not touching the keyboard she felt it was slightly harder to remain engaged in the coding task.

I suggested that they try a different version of pair programming - the one I know has people swapping places at the keyboard more frequently - and moreover that they should feel free to voice concerns about any part of their process and try experiments if any part of it seems not to be working too well, even for only one person.

Quite possibly, what prevents people from considering "pairing" is that what they consider is one of the less effective forms of pairing, and they rightly reject it. (I'm impressed with the willingness of the team at my client's to experiment with something that had half of them sit passively a lot of the time.)

LaurentBossavit 2005.03.28

Mike asked if anyone was mulling the possibilities of pair-programmers? That is, trying to imagine what it might be like?

Well, it didn't look like the people who were incredulous were actually thinking about it, but I wasn't inside their heads. It's possible they were trying to imagine ways to make it work and not succeeding. Maybe they were thinking of less effective techniques such as the one Laurent's client had tried.

I'm going to start discussing things the way Keith and Jerry framed them. Pair-developing is more enjoyable than pair-programming (Keith) and what happens when sports teams act as individuals instead of teams (Jerry).

Are there more ways to help people consider the possibilities? -- JohannaRothman 2005.03.29

Well, you can always talk about the process of making babies. <blush>

And that's not so silly, because nature figured out a long, long time ago that you get healtier, more agile (adaptive) offpring from some mixing of ideas (genetic material). That's why sex was invented, and why it has lasted for so long--and why it's so much fun, which encourages people to propagate the next generation. - JerryWeinberg 2005.03.30

Pair programming furniture, available today only! Check it out!

-- KeithRay 2005.04.01

I laughed out loud when I saw this. (Snorted too :-) -- JohannaRothman 2005.04.04

I don't program anymore (bittersweet). I do write a lot of things at home and at work. I am hesitant to put my writing up for peer review. I think mostly because I don't want to bother other people. They seem to have enough to do already.

Everyone now and then, I overcome this "don't want to bother" concept and ask for peer review. I did this at work late last week. Three people each took 15 minutes to look at something I had wrote and happily provided feedback. Their comments improved my work.

I see many people who don't want peer review of their work. The "I don't want to bother them" is one excuse. I suppose there are many others.

DwaynePhillips 5 April 2005

"They could not imagine that pairing would be useful, would be more productive than solo work, nor could they imagine how to write performance evaluations or give raises. What is it about pair programming (or pair writing or pair anything) that sets people up for such polar views?"

The first thing about PP is that it's not like anything else you typically do.

The second thing is that intuitively, people have different speeds, priorities and agendas and don't think they would be as effective if they had to constantly negotiate with a second party every few seconds.

What's more, I'm one of them. I have yet to see any studies that show that Paired Programming is effective. I don't regard anecdotal evidence from Kent Beck to be valid testimony (as he makes his living from showing how great it is). And the few times I've seen Paired Programming in action, it's been a complete disaster: people tripping over each other, arguing about brace style, the appropriateness of returns vs exceptions, etc.

For my part, Paired Programming slows me down because most people can't read and type as fast as I can. I literally have to stop what I'm doing so I can run through the code I've just typed, then explain what the stubbed out methods are going to do. And watching other people type is an exercise in frustration.

In short, it hasn't been a success, for all the reasons you would think it wouldn't be a success. Whenever you're introducing a new process, the onus is on you to show why people should pair. After all, they already have a method that works for them, and you're telling them that they shouldn't use that.

-- WillSargent

"...the few times I've seen Paired Programming in action, it's been a complete disaster: people tripping over each other, arguing about brace style, the appropriateness of returns vs exceptions, etc."

The next time you're in Silicon Valley, you're welcome to drop in on the company I'm with. We're an XP shop, and find that pairing works quite well for us. It's not always as fast as two people coding separately, but the defect rate (and resulting rework) is pretty low, and knowledge gets spread around pretty quickly. Almost all of us can work on any part of the system.

We screen candidates for their desire to be Agile, and their ability to collaborate, which has gotten us past the problems experienced by teams that are told by management edict that they must pair program.

Pair programming continues be studied, and there are a few academic papers available. http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF is the one that comes to mind.

DaveSmith 2005.05.12

To me, there's a big difference between the first time I pair with someone and the nth time, where n is greater than 1 or 2. The first time, I have to learn at what speed people think and type, what their idiosyncracies are, all that stuff. By the third time (and possibly the second), I know what to expect so I can practice calming :-)

The value I receive out of pairing is that the defect rates are very low. Much lower than they would be by myself. This past weekend, I was sitting on the couch, writing a script in FileMakerPro, with daughter #2 next to me on the couch. I wrote a script. She said, "Hey, how does that loop end?" She's 12. Not a programmer. (Yes, a logical mind :-) Sure enough, I'd created an infinite loop.

It's not a huge problem, having an infinite loop in that kind of script, but it would have been a pain. She caught it.

That's why I'm willing to try pairing with people. I found that pair-programming was much easier than pair-writing. Not because I was writing with Esther (that was fun!), but that the style is so much a part of writing, in a way that you can negotiate or remove in coding. -- JohannaRothman 2005.05.12

Dave, I have read that paper, but... well, it's not a rigorous study.

http://www.hacknot.info/hacknot/action/showEntry?eid=50

What I found most interesting is that all members of the experimental group volunteered to be in that group. To me, that's like having the left-handed scissor group composed of left-handed volunteers.

-- WillSargent 5/12/05

No, it isn't rigorous, and the sample is self-selecting, but groups of programmers are often self-selecting, too. Pair programming isn't a technique that I'd expect much success with by randomly selecting people and throwing them in together. I've worked with many excellent individual contributers who wouldn't be suited for pair programming at all, either because it doesn't match their thinking styles, or because they have trouble impedance matching with others.

When pairing works, I've found that it works very well. When it doesn't, it doesn't.

DaveSmith 2005.05.12

CanAgileMethodsGetInTheWayOfProblemSolving

ChrisHofstaedter 2005.05.24

WillSargent 6/7/05

A study in support of Pair Programming: "The Costs and Benefits of Pair Programming", by Alistair Cockburn and Laurie Williams. It may overlap a bit with the presentation linked to above.

(Link via KeithRay's blog.)

--DaveSmith 2005.07.27

Updated: Wednesday, July 27, 2005