Open communication is absolutely vital. Without a culture of openness, pairs may fall into a position, as Eric Johnson has described, where one resents the other’s greater insight. We found that it was important to ensure that it wasn’t always one member of the pair who ‘drove’.

There are times, however, when pairing just doesn’t give the results which its apologists trumpet. The worst case I’ve seen is a super-fast developer paired with a very slow developer with the result that the super fast developer took a week to do something that would normally have taken him solo 2 days to do (even allowing for bug fixing time, it would have been completed and QA clear in a maximum of 3 days). It’s important to pair people together who are fundamentally compatible, and not assume pairing will always give better results.

Some people are also natural loners, and they have their uses too. It will not automatically help (whatever their level of competence) to force them to work with others.

Finally, we had some interesting and good results pairing a coder with a tester. It isn’t something to do all the time, but it really helps, especially when writing unit tests, and in our case, doing UI coding, to have that extra “I bet I can break it this way” mentality on hand, to suggest extra things that developers might naturally overlook. For this, though, you need good QA people, and they are hard to come by.

The times when pairing has been a disaster is when the other party is unfamiliar with (and even suspicious of) the practice. Then it really does become 2x the cost or worse, plus it feels terrible.

We don’t pair as a rule, but we are careful to evaluate whether it is needed for each story.

@Alan Griffiths: I really like your idea of pairing a dev with a tester. Do you do this now and how does it work for you?

However, a lot of the code is relatively trivial, and having more than one person to write it is both wasteful and leads to over-engineering and extra complexity. I find that on the average 10-12 hours a week (that’s about 2 days) spent pair programming is usually enough, more is too much.

A better strategy is cross-functional regression-test (XRT) development.

In short, you write code, someone else writes the regression test.. and you write the regression test for another developer. In other words, everyone supports each other by developing regression tests for each other’s code. Nobody get’s out of writing regression tests and the culture of checking each other’s work through automated testing is collaborative… it rarely devolves into competition because everyone is transparent.

We use week long iterations and inside of a week we plan design implement and QA a small set of features. Yes, Naresh points out that it looks like mini waterfall, but we include daily scrums, deploying people where they are most needed, test driven design and it yields a highly productive and very agile process.

We started with 2 week long iterations, but found the meetings to oppressive, it seems 1-2 hours of planning for an iteration yields about 1 week of work and it seems that 1 week iterations are the sweet spot for our team. We have been doing this for 2 years now with a lot of success.

Common sense….

In the enterprise software dev environments in which I work, agile teams are increasingly asked to handle more and more projects, business domains, technology stacks — you name it. And all of this happens in a context of ginormous existing legacy codebases. For the average enterprise team, the effort required Herculean, and the results often feel Sisyphean. Pairing is essential to addressing all of this.

Defect risks arise from far more locales than the object model — we find defects all the time lurking in differences in deployment targets, in app server configurations, in un-tested database-resident biz logic, in requirements misunderstanding — again, you name it.

Enterprise programmers must “know” far, far more than ever before. More business rules, more technologies, more specific codebases, more integration details, more process details. For a given story card, it is exceedingly rare that an individual programmer can “know” all of what is required to test-drive an implementation without defects, design flaws, and requirements misses, at a high enough rate of production.

Only with pairing do my teams have a prayer of spreading required knowledge quickly and effectively enough. Only with pairing do I see risks being systematically reduced, and continuous improvement steadily improving. Only with pairing do I see high quality at steady, high production rates.

Only with pairing can I learn, BTW, which of my team members are just not skilled enough to keep pace. Nothing separates wheat from chaff like pairing them a few times.

I have tried dev projects many times both ways: with pairing and without. Regardless of your agile blend and agile context, if you are working in a complex enterprise SW dev world, you likely need more pairing, not less. The risks you thus avoid, in my experience, far outweigh the apparent short-term increase in labor costs.

I question, BTW, most of the research done so far on this. I think we have mostly crappy methods of measuring long-term productivity that takes into account overall defects, code debt, overall production capacity (how skilled and knowledgeable the team is overall), turnover costs from burnout, production losses from context switching, etc, etc.

Before I seriously entertain discussions about how valuable pairing is, I personally want to see a far greater swath of the enterprise developer community actually capable of doing it well.

You have an issue of productivity. Yes, for simple tasks you will loose 50% or even more, so, don’t use it for simple tasks. With wrong person you will loose 90% productivity, so, don’t do it with wrong person “just to do pair programming”. But for complicated tasks you don’t loose productivity at all. Even if the pair finishes project slower you will save time on bug fixing. The most important thing here is there are projects that can be done well by a pair in reasonable time but cannot be done at all if they work not together on the whole thing but on different parts of it. I worked on project like this.

I’m not practicing pair programming any more for several years. Why? I have no proper pair-programmer. There are some great programmers around but non of them is my pair.

The team has to work like a team. It has to be able to handle conflict. Tools need to be in place to allow mature engineering practices. Pairs should switch constantly. Co-location is critical. It has to be eased into (can’t be an all or nothing thing to start). Various levels of skill and domain knowledge increases its value. The team should be at least 4 people (two pairs) to allow rotation. A coach that can lead by example is critical in showing how it should be done and prove that it can be enjoyable.

Pair programming is easy to get wrong. I suggest it is the last of the XP practices to try since it is so fragile.

Some of the ways pairing adds more business value:

1) Continuous code review to ensure that obvious, or not so obvious, mistakes are not being created that would introduce defects.

2) Promotes code that is “readable” and greatly improves the long term value of a system by making it something that future developers can pick and start working with quickly.

3) Creates a collective knowledge of all aspects of the code base which reduces risks and the flexibility of team members to work on all parts of the system.

4) Discussion over implementation and requirements and a “double-check” of understanding of business needs. It’s easy for one person to misunderstand a customer’s needs, it’s more difficult for two people to misunderstand something in the same way.

5) Energized work – pairing keeps the development moving and allows programmers to “spell” each other by taking turns driving.

6) Pairing promotes the development of “simple” (but not simplistic) solutions that are easier to understand and tend to produce less code. This leads to less system complexity and overall size which allows new features to be added in the future with less work.

That’s why it certainly cannot be applied abroad blindly and must always be a case per case evaluation. I especially recommend it for teams that have a very high team spirit and for critical situation where there is a lot of unknown in the feature you want to implement. In those case, two people will work way better than having each of them in their own corner alone.

Don’t forget that while they are working on the same task, both of them are giving an effort on it. And since software engineering is not something that can be evaluated on quantitative production result (we are not making boxes), “When well done”, It is obvious that about the same value is given from a pair programming activity that there is with having both of them working separately.

It can be risky, but if you know your staff and your in control, then it’s a definite plus.

- Another Bob

My experiences with pair programming run the full spectrum. In summary, the vast majority of times it has not provided a net gain, but there have been a few instances where the results were fantastic (and I do not believe the project would have suceeded with out it).

So what has differentiated these experiences…..

The very best have been some occurances where I am paired with another senior developer on a task that requires strict attention to technical details and heavy conceptual work at the same time. In some of these (fondly remembered) cases, it actually involved me walking aoround the room, drawing on a white board, and giving verbal instructions. At the same time, the partner was concerned solely with the technical details of implementing my utterances and scribbles.

Similar effects are achieved when one member has strong technical knowledge, while the other has stronger “problem domain” knowledge. Individually they do not possess all of the required information to produce a world class solution.

Times when I have paired two juniors has often brought good results. I find this works much better than pairing a junior with a senior (more on that situation later). The “Thwo heads are better than one” principle applies here. If I find that the work results are becoming lopsided (they often do), then the pairs are shuffled. If a pattern emerges it makes “HR” decisions very easy.

For the senior/junior situation, I prefer to treat this as a mentoring scenario rather than a pairing scenario. This results in a different dynamic and different expectations. In most cases the number of hours where they directly work together is in the 8-20 range per week. During the remaining hours, the junior person “plods through” the directed assignments, while the senior person either mentors another junior, or actually performs senior level work.

OF course, these are just my experiences, but they have stood the test of time (the first example goes back to projects in the mid 1980′s – well before these methodologies were formalized).

The team was small and each member had a similar level of experience with the core technologies, but enough diversity in experience of the non-core technologies to make the development process double as a worthwhile learning experience for all.

Sometimes I find that I come up with a solution to a problem partway through explaining what it is, so having someone actively discussing something with me throughout the day prevents the occassional “can’t see the forest for the trees” situations.

I’ve talked to more than one person who quit programming because it was “lonely” and they needed to talk to people. They would have been much happier (and more productive) in an XP group.

There is a lot more to pair programming than personality, of course. One of my friends who is fairly introverted spent half a year or so pair programming, and says it was both one of the most productive and one of the most tiring periods of his life. The advantages of pair programming are the same whether you are introverted or extroverted, but costs are different.

I teach a software engineering class at Illinois in which the students all are required to practice XP, including pair programming. Some students like pair programming, some don’t. Like anything else, you get better at it with practice. Most people have trouble with it at first, but after practice they can see its benefits. Some people think it is wonderful. I haven’t done a careful study of it, but I bet the differences in how people feel about XP is related to their personality.