One of the most common issues I hear about allowing developers to pair program is that there are two people doing the job of one. I have to admit here that I have not been in the situation of being able to do much pair programming, but when I have I've found the experience to be very rewarding, and lately have been asking myself whether pair programming allows developments tasks to proceed faster than if a developer was assigned the task alone.

For most companies, the alternative to pair programming is code reviews. When using code reviews, a developer has (or creates) a design and goes about the task of implementing the design. After the task is finished, the programmer meets with one or more of his peers for a review of the code.

The problems I see with code reviews are:

• The design of the program elements or bug is at a high level
• The implementation of the design could takes days, weeks or months (depending on how agile the company is) and during this time the design of the program element usually changes
• The new design elements may not (and usually have not) been reviewed or discussed
• The code reviewer generally neither has the time or the seniority (or perhaps even respect) to require that the changes specified are made
• The code reviewer usually does not understand the problem context as well as the developer, and can miss potential problems the code review is designed to find

This leads to a scenario where two thing's can occur: the currently implementation is kept, decreasing the quality of the code base (and increasing maintenance costs) to avoid the additional time to fix the problem correctly (usually due to project schedule deadlines); or the changes are implemented, and depending on the extend of the code modified, the implementation time for the feature or bug extended (sometimes significantly).

So how would pair programming make this different? First, the code is under constant review - each program element and design decision would be discussed at the point that it became relevant. Additionally, and more important to ensure the code developed solves the intended problem, each developer would know the context of the problem space. Developers also work with each other to answer development questions, ensure code quality, tests are developed, and standards and development processes are followed correctly.

Which is best for your company? I think that depends on many factors, but if your goal is to create quality code that reduces the cost of maintenance and adding new features - pair programming may be worth a second look and not the loss of productivity it is believed to be.