Making Software

Challenges

The results discussed previously indicate that teams benefit in a range of ways when using the pair programming practice. However, several challenges prevent widespread adoption of pair programming. Four of these challenges are now presented. In this section, we also suggest how these challenges can be overcome.

Bias/habit

Software engineers can be conditioned to work alone, particularly those who were not educated using the pair programming practice. As a result, many can be concerned that they will not be able to concentrate when working with others, that they may be “wasting their time” with slower programmers, that they will feel inadequate compared to their peers, and other concerns. However, of those who try the practice, more than 90% prefer pair programming over solo programming [Succi et al. 2002], [Williams et al. 2000]. Because most engineers eventually learn to like the practice, a strategy for overcoming this challenge is to institute pair programming as a nonthreatening pilot with a small number of engineers. These engineers are likely to find the practice beneficial and will be more likely to ask a colleague for a spontaneous pair programming session when facing a challenging programming task.

Economics

Despite research results to the contrary, software organizations can be concerned that pair programming will double software development cost, as two programmers are working on one task [Begel and Nagappan 2008]. A manager at Microsoft was quoted as saying, ...