Pair Programming
This page is a set of notes on pair programming. This is by no means a definitive list of the pros and cons.
Advantages
Code Quality
There is no doubt that code produced through pair programming will be of a better quality than code developed by a single engineer on their own. The primary advantage is that all of the code is subjected to a constant code review that should catch most errors as they are being written.
Training
The most cost efficient way to bring a new, inexperienced member of the team up to speed is most probably pair programming. They work with an experienced developer and learn from everything that they do and pick up not only knowledge about the company processes but also better programming techniques. The downside is that the experienced programmer will have their productivity impacted by having to explain each step.
It should be noted that training does not have to be for inexperienced members of the team and pair programming should be used whenever it is a suitable method for transferring information such as the use of an API or product.
Disadvantages
Developers may not want to work with other people.
It is not fair to ask existing members of the team to change their working environment by the amount required for pair programming and expect them to be happy about it. Staff morale is the most important productivity tool that the company has and nothing should be done to jeopardise it.
It is unclear how large the benefits are
Although it cannot be denied that introducing pair programming into a traditional environment will improve code quality (ignoring the productivity issues for now), and research has gone some way to prove this (see www.pairprogramming.com for links), there is some doubt as to whether the gains are as great in an environment where an aggressive testing policy such as the use of aggressive amounts of unit tests are high enough to justify doubling the man hour resources in this way. XP makes it more beneficial by eliminating design and using pair programming as a safeguard.
Pairs are not always available
If pair programming takes two people what does the third member of the team do? Even if you are planning projects to have a even number of programmers there are going to be times where illness, holiday, working from home or train strikes prevent pairing for one or two members of the team from being allowed to program. XP says that they should be given tasks such as documentation for that time, but under XP with it's de-emphasis on documents such as software design documents ("The code is the design") this seems like make busy work. Staff want to be able to work from home. Staff want to be able to take a nice looking problem and solve it on their own. Staff morale is the key to productivity and needing a pair to program will damage the feeling of freedom that the developers currently have.