I've led agile teams for the past three years where there has always been some pairing and some solo work. I'm sorry I can't offer statistical data, only my anecdotal observations:
* Pairing is particularly useful when breaking new ground.
* Pairing is good for knowledge sharing.
* Pairing is good for quality.
* One pair is slower than two solo developers.
* Based on the last 3 years I don't buy the idea that long-term pace is higher because we'll have less technical debt due to pairing.
* Improved quality may not be worth the lower overall pace
* You hired professional developers - let them work the way they think is best or find new developers i.e. respect their preferences for pairing or going solo.
I think most of the points you make a pretty good points. I have not worked in a pair programming environment myself but find it quite attractive. Mainly because sometimes I tend to rapidly analyse multiple ideas for pros and cons and to try and break them and having someone as a sounding off board is something that I would like.
Sure - this point starts with the idea that pairing is slower in the short term but creates higher quality software. We might also believe that pairs will create systems which are easier to maintain i.e. pairing leads to better systems design. So, we might believe that it will be cheaper to change those systems in future and we won't be spending so much time fixing 'technical debt' (solutions which turned out to be poor technical choices). Some advocates of pairing will claim that this means pairing will actually be more productive than solo work in the long term (since those solo folks will be spending more time wrestling with poorer quality code and less well-designed systems). In my (limited and subjective) experience I haven't found this to be the case.
Ah.. Oh.. Well, logically, I came to that conclusion as well (as indicated by my comment)
You comment indicating otherwise needs more investigation. I wish there was some statistical data to help determine this more conclusively :)
* Pairing is particularly useful when breaking new ground.
* Pairing is good for knowledge sharing.
* Pairing is good for quality.
* One pair is slower than two solo developers.
* Based on the last 3 years I don't buy the idea that long-term pace is higher because we'll have less technical debt due to pairing.
* Improved quality may not be worth the lower overall pace
* You hired professional developers - let them work the way they think is best or find new developers i.e. respect their preferences for pairing or going solo.