Extreme programming (XP) introduced most people to pair programming.
The theory was that the sooner that code was reviewed, the more effective the review -- so how much more effective can you be if you do that review right away?
The reason it isn't a better practice is that two people are being used to produce a single result and so it is not very efficient. For more information about the marginal productivity see Capers Jones1.
However, as a team building tool, pair programming can be extremely effective used in specific situations where high productivity is maintained:
It also gives you a fairly good glimpse into how that team member will work with the group.
The key here is that the new member should pair program with different people every day until they have worked with the entire team. This will speed up the integration of new members and get everyone familiar with each other.
Surprisingly, it is not just the less experienced programmers that learn from the more experienced ones. Often, more experienced programmers have picked up habits that they are not even aware of.
Working with newer programmers can expose you to information on IDEs and new productivity tools that you are not aware of.
As much as we do keep up, there is continually new stuff coming out and the newer programmers are aware of it.
In addition, there are sub-optimal habits that we all pick up and no longer notice because we do them all the time.
Planning is 1/2 the work, making sure that you implement that plan can often require two people to make sure that all loose ends (exceptions, boundary cases, etc) are taken care of.
In particular, these are the sections of code that you want two pairs of eyes on as you are much more likely to recognized a missed alternative or work through weird conditions.
The theory was that the sooner that code was reviewed, the more effective the review -- so how much more effective can you be if you do that review right away?
Pair programming increases productivity by 3% and quality by 5%
However, as a team building tool, pair programming can be extremely effective used in specific situations where high productivity is maintained:
- Training new team members in coding conventions
- Sharing individual productivity techniques
- Working through complex sections of code
New Team Members
The first issue is self explanatory, pair programming allows you to explain your coding conventions while working on actual projects.It also gives you a fairly good glimpse into how that team member will work with the group.
The key here is that the new member should pair program with different people every day until they have worked with the entire team. This will speed up the integration of new members and get everyone familiar with each other.
Sharing Productivity Practices
One of the key benefits of pair programming is that it is an ideal time to share productivity practices.Surprisingly, it is not just the less experienced programmers that learn from the more experienced ones. Often, more experienced programmers have picked up habits that they are not even aware of.
Working with newer programmers can expose you to information on IDEs and new productivity tools that you are not aware of.
As much as we do keep up, there is continually new stuff coming out and the newer programmers are aware of it.
In addition, there are sub-optimal habits that we all pick up and no longer notice because we do them all the time.
Working Through Complex Code
Once you have planned a complex section of code, it can be very helpful to build that section of code as a pair. For information on planning complex code see:Planning is 1/2 the work, making sure that you implement that plan can often require two people to make sure that all loose ends (exceptions, boundary cases, etc) are taken care of.
In particular, these are the sections of code that you want two pairs of eyes on as you are much more likely to recognized a missed alternative or work through weird conditions.
Summary
Used appropriately, pair programming can be a great tool for integrating new members into a team, sharing productivity techniques, and reduce defects and improve quality of difficult sections of code.References
- Jones, Capers and Bonsignour, Olivier. The Economics of Software Quality. Addison Wesley. 2011
- Jones, Capers. SCORING AND EVALUATING SOFTWARE METHODS, PRACTICES, AND RESULTS. 2008.