Are two heads better than one?: On the effectives of pair programming

While working my way through graduate school in the mid-90s, I took every chance I had on summer and holiday breaks to go back to work as a software developer. Luckily, I worked for a great boss and a flexible organization, which could usefully put me back to work extending the applications I worked on during my previous visit. If there was a downside, it was that I usually got assigned to whichever random desk was open during each visit. All too often, I ended up at the dreaded solitary desk in the windowless server room, among the empty computer boxes and the walls of sheetrock and spackle. These experiences (which are not so uncommon, I suspect, among junior software developers) are probably among the reasons why I've found pair programming (PP) so interesting. Many developers, and not just those who have ended up programming alone in windowless offices, have been excited by the paradigm shift, while others seem extremely annoyed by it. In both cases, perhaps the most important result is that PP leads to rethinking about the concept of development teams and about how individual programmers can best contribute to the project. Now that PP is several years old and has seen increasing interest and adoption, it's useful to consider what has been learned about its more specific effects. The evidence certainly provides proof of its benefit, although not in all cases and perhaps not in the contexts that many developers would have thought