Pair Programming The Wrong Way

We tried PairProgramming, but implemented it very badly.

The junior staff paired to build the well-understood functionality from cookbooks,
The pairing was assigned and permanent for three weeks,
Tasks were assigned to the pair, who did have the option of working separately, but had joint responsibility,
Since the junior staff members are located in small cubicles, both partners could not reach the terminal at the same time. Instead, one person would type, while the other sat back a few feet away and watched.

I would like to understand this better. Those look like reasonable (not 'fun') setup rules for PairProgramming in a standard industrial environment. Assigned tasks, small cubicles, one person drives, 3-week assignments all seem to be fairly natural. And yet, contrary to expectations, it did not work. Can you add any insights you have as to what caused the problem, or what might have fixed them, or how it might have been set up, with the same people, to avoid the problems? Would coaching on the technique have helped? thanks -- AlistairCockburn

I'd also really like to understand this. What went wrong? -- PeterMerel

This setup doesn't sound remotely appealing to me. I'm looking for complementary insight and moral support from my partner. It doesn't sound like this work required much insight. Nor was the work aggressive enough to need moral support. Try pairing junior and senior. I've paired successfully with very junior people. They have to bring something to the collaboration though. That something can be as simple as having spent the day before studying the API documentation. We might make such an agreement ahead of time. -- WardCunningham

PairProgrammingFacilities
InformalLaborPlan?

Thanks Ward. I realize the misimplication in my words - "reasonable" to me meant "reasonable set of constraints to find in an industrial programming organization", not "fun" or "appealing" (the italics are my changed text). It doesn't sound terribly appealing to me, either. My interest is because I didn't read anything that would have indicated to me that is wouldn't work. "Assigned tasks, small cubicles, one person drives, 3-week assignments."

I don't think one can do anything about the cubicles or one person drives...I thought you said you worked PP fine in private offices in Wycash, and there is only ever one person typing anyway, the other person sitting beside or behind. That leaves assigned tasks - which is not really unusual, and 3-week assignments. I shall be surprised if 3-week pairings turns out to break PP.

That leaves two possibilities I can now see, thanks to your comments:

The first is that the overall methodology is of the "senior designers get offices over here and do big thinking, while junior designers get cubicles over there and do simple-minded programming" variety. This would create an environment in which thinking is stifled, along with being personable and communicative, and there is not much opening for the sorts of coding and design changes that come with PP.
The other is They have to bring something to the collaboration though. That something can be as simple as having spent the day before studying the API documentation. With nothing for them to chew about, and little reward to scope for chewing, there is little for the second person to do, besides fall asleep behind the first. -- AlistairCockburn

I've had a very good experience as a "senior" person, pairing up with student interns who have grown up with the latest whizzy stuff and still have some energy . They get someone who's been through a couple of different things, and I get a guided tour through JavaSoft's latest offerings. -- SteveFreeman

Some of the problems I observed:

As with any imposed process change, the going-in implication is that those ordered to change are not considered competent enough to succeed. Without experienced mentors showing the advantages, a process change seems punitive.
None of the junior programmers understood the idea behind PairProgramming. Typically, they saw it as having someone else looking over their shoulder because they could not be trusted to do a good job. Conversely, the non-typing partner did not understand that kibitzing was not only welcome, but expected.
They were resentful that all of the interesting tasks had been assigned to the senior developers
Since the non-typing partner could not reach the terminal or even see it clearly, he or she was generally unable to make the as-you-go comments that seem to be essential to an effective partnership. Instead, they felt condemned to watch passively while someone else did the real work. With experience in PP, they would at least have felt obligated to kibitz.
Not all personalities mesh well, especially in an organization full of natural loners. This setup guaranteed that people who did not know how to work together were condemned to do so under unfamiliar and stressful conditions.

-- RussellGold

Re: "I don't think one can do anything about the cubicles" I have been amazed at how much my teams can do with their space once they have permission to break the rules. And it is critically important that the partners sit side by side. You have to be able to see each other clearly, and to switch roles without having to move anything but the keyboard and mouse. You can't do this with standard cube set ups, but half an hour with a screwdriver and/or an AllanWrench? can work wonders. And if the team won't spend half an hour on their own space, what are the chances that they are ready to take responsibility for improving their software process? -- kb

Related to that, if the team is not allowed to spend half an hour on their own space, what are the chances they feel allowed to take responsibility for improving their software process.

Thanks for all the clarifications, I certainly learned something from them. -- Alistair

[comments moved to PairProgrammingErgonomics]

We learned some fundamental rules for the PairProgramming construct itself, after seeing some of the above occurrences on VcapsProject:

Never pair two people together who are brand new to PairProgramming (always one old-timer with a newcomer)
When a pair takes the option of working separately (but with joint responsibility), they aren't really PairProgramming
If both people can't see what is happening on the monitor, they aren't really PairProgramming
Everyone works in a pair (no LoneRangers allowed)
People have to Trust each other, and it may take time to build trust among everyone on the team

I think most people who have done PairProgramming unsuccessfully (and then successfully) have learned these sorts of rules of thumb. Although I find it is good to take "refresher courses" from time to time. -- JeanineDeGuzman

Please note that the first rule above makes PairProgramming inapplicable to most environments. We must start with people who are brand new to pair programming, but to date our attempts have been such miserable failures that I doubt the value of pair programming.

Why can't a pair practice pairing outside of the work environment, get used to it (despite all the frustrations and annoyances that make it unproductive when two new Pair Programmers start out), then introduce Pair Programming to the team? It strikes me that a few hours spent at the end of the day, once or twice a week, would yield significant results within weeks. -- BrentNewhall

Why is doing pair programming outside of the work environment any more likely to be successful? It would seem that not having a common work goal and doing "play" programming after hours would only exacerbate the problems.

CategoryPairProgramming