Pinderkent

While some descriptions of pair programming suggest that "all code to be included in a production release" is to be developed jointly by two programmers working in tandem at a single computer, that isn't a steadfast rule.

Teams wishing to employ such a development technique can be flexible about their pair programming arrangements. One team I worked with in the past only chose to use pair programming while developing the most critical parts of their software system. This allowed for the core functionality to be well-understood by all of the developers, but as soon as that work started to stabilize, they each went back to working on code alone. But as soon as core functionality had to change, pair (or even triplet, in some cases) programming was used.

This proved quite effective. Code that the team agreed was trivial could quickly be developed by a lone developer without too much overhead, while more complex or critical changes still had the oversight and involvement of at least several team members. They managed to strike a very good balance, which allowed them to develop their software quickly and efficiently, while also helping to keep the number of bugs to a reasonable level.

Other teams using pair programming shouldn't be afraid to experiment with introducing some flexibility into their process. It is possible to practice pair programming even if it's only done some of the time, or even just when absolutely necessary. Given that each development team's situation and software system is different, some teams may be best of pair programming only 20% of the time, while others are best off pair programming at or near 100% of the time. It should be tailed to each team's specific needs.