When does pair programming work? When to avoid it?

Question

Rather than slavishly pair program all the time, we use pair programming selectively on our team. I think it works best in the following circumstances:

• Ramping up brand new team members on a project (instead of letting them wade through documentation or code on their own).
• Having junior and senior people work together (helps to show some of the skills and tricks of the more experienced developers, plus it allows the old dogs to learn new tricks sometimes).
• When someone is trying to track down a defect, it often helps to pair with a fresh set of eyes.

When to use pair program and why?

When to avoid pair programming? Why?

Answer 1

Research compiled by Laurie Williams indicates that pair programming works best on industrial teams when

• Pairs work on specification, design, and complex programming tasks - experiments indicate that no quality improvement is shown when working on simple tasks in a pair but there may be speed improvements. Also note that pair "programming" often includes activities other than writing code.
• Each individual in a pairing has about the same level of expertise - while pair programming is great for training, pairs are most engaged when they are about on the same level.
• Roles rotate regularly - rotating regularly helps keep the current copilot engaged as individuals tend to contribute most when they drive or sense they are about to drive.
• Pairs rotate regularly - teams have expressed comfort in knowing about different parts of the system they are building. Pair rotation helps with knowledge transfer which reduces certain risks in the project. In an academic setting pairs are often assigned, however industry they are generally self-assigned often during stand-ups. In both cases, the pair is most effective when both individuals are willing participants who see value in the pairing activity.

In my personal experience I've found that my XP team spends about 60% of our development time pair programming on average. The remainder of the time is spent doing individual development. It is not uncommon to pair up to create an initial design, work alone on the design for a few hours, then come back together to finish tricky or difficult parts of the code.

I've also found that pair programming is most effective in approximately 1.5 to 2.5 hour blocks. Anything much less tends to require too much overhead to setup while much more and the pairs tend to get cranky and tired. Cranky and tired means you're not communicating well and might be letting defects slip into the system.

Answer 2

Pair programming has worked for me in very, very few situations.

Where Pair Programming Fails for Me

The short story is that pair programming doesn’t work for me as the main way of developing software. I can pair program for a day, or maybe a week, especially if we’re focused on a particular problem. But after that? I’m done. Toast. I don’t want to see anyone, talk to anyone, and I need at least a couple of days in a cave until I’m fit for human company again.

It’s a sad story, but the funny thing is that I’m so much happier now with how it ended. I’m happily employed on a contract where I work from home or from a coffee shop, and I’ve made new friends and explored more of San Francisco than I ever thought possible. I have a bicycle and a laptop, and as long as I meet my deadlines and check in code regularly, my time is my own.

I’ll list the big problems I have with pair programming up front and give you the detail and anecdotes later.

1. Split focus.
2. No experimentation.
3. No high notes.
4. No pride in ownership.
5. No escape...

...I asked my co-workers if they saw what I saw, if I was missing something, anything -- I didn’t see how this could work, how people could keep doing this. They said I was doing fine, that it just took time to settle in and adjust. That it was hard for everyone at first.

Eventually, I retreated into myself. Between the blinding headaches, the insomnia, and the pounding, unmet need to write code, I stopped responding to input. I could stare at a screen and not see anything. Someone could talk to me unexpectedly and I wouldn’t hear them. I was fulfilling the rote requirements of my job, but I wasn’t there. I’d used up everything I had just showing up for the day. I started checking my iPhone when my other partner was typing.

Finally -- just shy of three months later, and for the first time ever -- I was fired for not being a team fit when pair programming.

Not Alone

I wrote this not just to understand it, but also to be able to talk about it. There’s been a presumption that pair programming works for most people and is much easier and faster than programming solo would be. This may or may not be the case, but as a long term practice, pair programming doesn’t work for me. There are many other people that pair programming doesn’t work for either. We matter too...

Answer 3

My team has done pair programming since its inception, long before I worked there, as part of a mostly "extreme programming"-style shop. Pair programming is the default state; people only really go singleton if there's an odd number, or occasionally for investigations, especially those which will involve messing around with hostile equipment and trying to get it to work.

"Junior/senior" isn't the only way to go. "Intermediate/junior" is useful; it helps the intermediate-level guy synthesize the knowledge he's obtained by forcing him to communicate it to someone else. "Intermediate/Intermediate" challenges two people work together to share their knowledge, communicate, and work as part of a team. And even if you have two really senior guys, chances are they have different areas of expertise and can come up with different approaches. The knowledge-sharing aspects don't end once someone's vaguely "up to speed" on a project. Rather, pair programming is the epitome of a learning organization. New techniques and best-practices spread rapidly.

Pair programming also helps maintain the quality of the code (fewer defects) and the sanity of the code (it doesn't just do what it intends to, but does what it should... ideally without going down a multi-week rabbit-hole doing the wrong thing, or two different right things that will conflict wildly). It helps the programmers maintain their focus: here in the heart of Silicon Valley, home of the 80-hour work-week, we can work for just 40 hours a week because we're doing intense coding for eight hours a day, switching things off with one another. (Also, if you went longer doing pair programming, you'd probably flip out. Or at least burn out.) This is great for work/life balance, and it also helps your organization when it's important to have fast turnaround (low-latency turnaround, in particular).

It's not all, completely, 100% peaches and cream; I find that pair programming is occasionally an obstacle to my application of intuitive brain processes which are useful on certain problems. Most recently, on a memory-leak task, I spent some time both with and without pairs; without one, I felt more free to mess around and try experiments without really knowing exactly how to explain what I was doing at any one moment. There are also some advantages in working singleton, being able to go off on a tangent and do certain wild refactorings (valued in the XP methodology) on a whim.

But all told, the benefits far outweigh the costs, and pairing has worked out spectacularly well for us: from the start-up stage through acquisition by a larger company, and our subsequent integration. (Speaking of which, pair programming has assisted us with maintaining a continuity of culture through expansion and despite a little turnover).

(We develop a software appliance in Perl, ~$4,000-$40,000 list price.)

Answer 4

I have never worked in a "Pair Programming" setup and yet I can claim to have been a part of the three circumstances you've listed. The scenario you mention seems more "regular programming" with phases of helping / training thrown in. Did we not do all of this before "pair programming" came into being? Pair Programming, I'd assume would require a more committed approach where the process of sharing within a team doesn't stop the minute you tackle the immediate task or problem at hand. But then this is what I "think" not what I "know".

Personally for Pair Programming I'd like to work in a team where I get a chance to learn and share my knowledge. An unbalanced team where everyone you work with is miles ahead of you, or then way below par can get quite uninteresting quite quickly. Also, I'd be afraid to work with people who are set in their beliefs and hard to convince.

Answer 5

We have been experimenting with Pair programming in our team for the last few months. I feel its pretty useful when you are working on something new (new technology, new feature etc) as you can quickly bounce ideas with another person of the team and have them validated/invalidated. Also, a side by side peer review helps in keeping bugs out.

Another teammate tried using pair programming with a test to do ATDD and they were quite happy with the results (according to his calculations a increase in 20% dev cost led to a decrease of about 50% in test time)

Answer 6

Working on anything of non-trivial complexity tends to be a good candidate for pair programming so that multiple people understand the code rather than just one developer knowing a portion of the code base. Another case is where someone is wanting to transfer some skills. An example here may be having someone that is really good at unit tests pair with someone not quite as familiar with the concept and thus helps to get an initial habit on something.

As for where to avoid pair programming, grunt work tasks that are straightforward where it would be better to divide the work into two groups and let each developer do some of the work separately to get the work done. Some tasks can just require a fair bit of typing but aren't so big that it is worthwhile to spend a few hours trying to find a better way to do it as it could be done if each developer takes a brute force approach for a few hours.

Answer 7

Good night

many times we have debated about practices of Extreme Programming and the pair programming. Back in time, we are able to understand that programming is a solo activity because programmers needed concentration and isolation. The programmers at that time were in the zone, a mental state where they could efficiently focus on the code and make nice and creative decisions.

Pair programming seems to be also risky if you assume one programmer interrupts each other. On the other hand, it's more difficult to interrupt two programmers working together. On Solo programming for example, it will be easier to be interrupted, so it's almost impossible to a solo programmer to stay in the "zone".

The code quality is another when dead line is just around the corner. People will be always in a hurry, be a pair programmers or a solo programmer: they will not apply certain best practices and will just forget about unit testing.

I would stick with pair programming. Because when it come to risks, when one programmer is gone, you will always have another guy to document the process and teach everyone else how it works.