This is a great article in the IEEE Software journal looking at why pair programming does and doesn’t work and why it should or shouldn’t work.
In fact the article doesn’t have all that much to do with pair programming but looks at how developers work with each other. The article sites 4 mechanisms where pairing can have influence.
For example, the great scenario whereby describing a problem to an ‘expert’ colleague helps you find the answer, even if the colleague has little idea about the problem or the domain to begin with. This reminds me of the Code Consultant plugin for IntelliJ Idea.
Or when someone misses an error right in front of them (inattentional blindness), a pair can pick up the error. The old psych lab of Did you notice the woman dressed as a 400 pound gorilla in the picture the second time around?
The article talks about how pairs can help keep each other using proper development patterns over change, compile, run, fail, change something else, compile, hope for change loop that beginners use when they first start developing.
Finally, the article talks about how having a pair helps get a view of your own self since developers working solely don’t usually have their techniques reviewed critically and often, working with a pair also enforces them to do some introspection. A yard-stick? People who don’t pair are less likely to do this, and the article sites the scenario where job applicants who claim to know something, get stuck when it comes to explaining these things in practise.
Overall, I think it was a good article, not because it was talking about pairing, but more because it highlighted the tribulations of everyday developers, and how pairing could help or detract as an afterthought.
