Thoughtful Reactions Pair Programming

How to engage "lone wolves?"

Lone wolves can be a problem. Perhaps lone wolves ARE a problem. They might be incompatible with other team aspects of XP, such as team design, coding standards, etc etc.

There have to be more guidelines for this. Sometimes a module is too small for two people and one person can better handle it.

This sounds like an objection from someone who hasn't done much PairProgramming. It's not like two people programming, it's like one very smart person programming. There's room in a single method for two people ... and certainly in a single module.

Also, using a fairly thorough design/code review regimen, you can make sure no one gets away with shoddy work.

Yes, you can get that effect with reviews. PairProgramming isn't about discovering shoddy work, it's about producing quality work faster. PairProgramming does prevent flawed work: it is far better than reviews due to faster feedback and more effective use of people time.

We sometimes refer to pair programming as "RealTimeCodeReview?". The give and take between a pair about how to approach a problem tends to be much more effective and efficient than the inquisitorial-style formal code review. By the time you get to formal code review, the original developer's investment in the original solution creates a lot of friction, even when the review process is working fairly well. -- BillBarnett

Finally, if you're working on a time-critical piece, sometimes you have to get it done and a inexperienced partner slows you down.

I've never seen this happen. The least experienced partner on the team always makes my work better. It's humbling and empowering at the same time.

The concept of pair programming is not universally applicable.

It definitely does not apply to singleton programmers. It has been used effectively with programmers not in the same location, so geographic disperson isn't enough to knock it out. In what other situations might it be literally inapplicable?

Could you explain how you pair program when geographically separated a little more? -- AlanKnight (Perhaps on VirtualPairProgramming, which needs elaboration.)

I've found that I always build better software when I have someone else there, even if the other person doesn't write software. Just having someone there to talk to while I code helps me to understand the problem better. Some of the best code I've ever written was created when I was working at the keyboard with another developer. -- CarlGundel

We used to think that the primary benefit of pair programming was that it helped us add people to the team quickly by bringing them up to speed and helping them understand our approach. One senior person paired with one junior person was ideal, and if we couldn't achieve that we were losing some benefit. We now believe that pair programming is MOST effective when we can pair really senior people together -- they experience a quantum jump in efficiency, clarity, and quality. And, as a nice byproduct, they really enjoy the experience.

We have observed that there is risk in pairing two newbies, because they can reinforce bad thinking and encourage each others' bad habits. Have you ever heard the Car Talk guys discuss whether two people who don't know what they're talking about know more or less than one person? <g> -- BillBarnett

During interviews, we are keenly interested in what candidates have personally accomplished.

I'm quite sure that pair programming doesn't preclude personal accomplishment, or measuring it, although I'm not quite sure how to argue that point.

But perhaps it's more important to be concerned about contributions to a team than about personal accomplishment. After all, that's your goal: for your project teams to succeed. You are focusing on one particular way to achieve that (looking for employees with stong records of individual accomplishment). Focus on the goal, not the means. Consider that there may be other paths to the same goal.

(As a pathological example, PeopleWare tells a great story about a woman who didn't contribute anything particularly visible or noteworthy to her projects, and the project managers were considering firing her. Until TomDeMarco and TimothyLister pointed out that every team she had ever been on succeeded (in an organization that had a lot of project failures). They concluded that she made some important but intangible contributions to the cohesion and viability of her teams. You decide: was she a valuable employee?)

The original objection, that pair programming makes it hard to tell individual accomplishment during interviews, can be turned on its head. I've talked to some XP folks who now interview new people by bringing them in for an afternoon and having them pair with a couple people on the team. They work directly on production code, and by the end of the day they know much more about a person's skills and personality then they could ever learn from an interview. -- WilliamPietri

Weak teammates can require lots of hand-holding ...

As mentioned above, pair programming can be one of the fastest and most effective ways to rapidly turn a weak team member into a much stronger one.

If they are a hopelessly, permanently weak teammate, then that's a personnel problem that no methodology can fix. And if you aren't sure, pair programming is a very fast way to find out.

... and their lack of contributions can be hidden by pairing.

This might be true if people worked in the same pairs all the time, but XP recommends constant flux in pairings (often more than once a day). If someone is weak and doesn't contribute, doesn't learn, doesn't improve --- soon the whole team will be aware of this.

Contributors: RonJeffries BillBarnett CarlGundel GlennVanderburg

PairProgramming seems to suggest that you switch partners often, while UserStories are intended to be 1 - 3 weeks in development duration. This appears to require that you will also switch between UserStories several times a day. How do you prevent loss of continuity? Or do you find less need for continuity in an XP approach?

WayneMack

The tests give you much of the continuity. You can read them to see how far you've gotten. I write ToDoList's on an IndexCard while I'm in the middle of a task. --KentBeck

Alternately, pairs can be assigned to work on EngineeringTasks rather than UserStorys. EngineeringTasks tend to be short (on a scale of hours), and thus are more amenable to switching like this. -- BrentNewhall