That didn't work over so well. The other developers in the group didn't want to pair up and some claimed that it created an uncomfortable working environment.
Today pair programming is a bit more accepted and understood, but I'm still not convinced it provides value in all development tasks and for all teams. I think pair programming is very appropriate when bringing new team members into a group as a form of training. It may also be useful in complex refactoring exercises, programming efforts that require significant object oriented designs, or development work on algorithms or procedures that have performance considerations. I'm sure there are many other tasks where there is a strong argument for pair programming.
But there is a danger if a team adopts it as a standard, default practice. In every development cycle, there comes a point where the team is challenged to take on more tasks either to meet a deadline, react to market conditions, or handle risks. At that point, the team may be challenged to break pairs in order to take on more work.
I know what some of you are saying. Breaking pairs doesn't necessarily mean more tasks can be completed, and there is a risk that breaking pairs will reduce code quality or create more defects.
That said, I think a healthier approach is to budget for pair programming. Consider the following approach:
1. Given an iteration, one pairing team is established, what critical tasks would be assigned to that team?
2. Then look at the remaining tasks and decide which of them could be addressed using a single developer and introduce the least risk. Assign these tasks to individual developers.
3. Repeat this exercise until all tasks are assigned.
4. Look at tasks assigned to individual developers (non-pairs) and evaluate the aggregate risk. Consider other options to derisk including code reviews and additional testing.
5. After the iteration completes, the team should reflect on overall quality. Tasks where pair programming was applied, determine what benefits were realized. Quantify (or at least qualify) these benefits. For single developer tasks, quantify/qualify risks realized. Catalog this reflection.
6. Consolidate (5) into lessons learned. Apply these lessons to subsequent iterations.
By following this approach, a team can formulate a more scientific and defendable position on when to apply pair programming.