Pair programming has been adopted in many agile and XP derivatives. It has stood the test of time and the sign that it is still being used in various flavours suggests that it has something to offer. Do the pro’s outweigh the con’s?Pair programming is one of those practices you either love or hate. The experience depends vastly on the person you work with and how much tolerance the pair is able to exhibit.My experiences have taught me:

Discipline Matters: There is more of a tendency to chat/talk and get distracted than when you are by yourself. Stay focused on the task at hand and keep each other motivated. Pair programming only works when two people both work productively and collaboratively.

Introduction Period: It takes time to get used to working side-by-side somebody else (in a productive way). In the initial stages the pair will probably spend a lot of energy questioning each other and their respective approaches. Expect a small amount of friction.

Exploration and Exploitation: Be willing to learn and try new things whilst at the same time be willing to compromise with your partner to exploit benefits they may be able to bring to the table. A healthy mix of exploration and exploitation heads towards good team cohesion.

Moderation: Nearly everything has its limits and pair programming is no exception. Whilst work should always be done with both members present, the longer the sessions and frequency of meeting the higher the agitation factor. Working with anybody all the time for too long too frequently can cause problems. One or both members are likely to become agitated, sick of seeing the site of the other member (everybody needs space). Productivity at this point goes out the window as most of the time is then spent arguing. If you can see signs leading towards this, take a bit of a break.

Equal Footing: It is important that the driver and navigator swap positions every couple of hours or as required. Both members need a chance to work through the code first hand. Similarly, both members need a chance to sit back and reflect, plan, critique, suggest…With time and practice, a good pair of programmers can increase each other’s efficiency and quality of work. Whilst pair programming (from a business sense), may cost more (two resources on one task). The overall quality and output produced in most cases, justifies this. Often the largest cost in software development is software maintenance. This maintenance can be greatly reduced by a much higher quality product being produced in the first place.

The hardest thing with pair programming is that no metrics exist to easily capture the effectiveness of the pair. Juxtaposing this metric with that of each member individually could help track pair efficiency.

One big disadvantage that I have found in pair programming and agile development in general is the lack of support for weak technical capability. The greater the technical diversity between the project group or programming pair, the less each group is able to achieve. Too much technical diversity in most groups, I have come to realise, is a real show stopper.