4 ms·
When our manager discovered us pairing, we had to defend the practice against the objection that it would surely halve our productivity. I think those of us wh
by arebop 18y ago
When our manager discovered us pairing, we had to defend the practice against the objection that it would surely halve our productivity.
I think those of us who initiated pairing on our team were the most motivated programmers, and those who wound up pairing regularly were likewise the most enthusiastic about the project and about professional development too. I'll admit that it's hard to separate causes and effects here, but I do believe that on our project, pairing was more of an effect of our desire to improve our productivity.
- richcollins 18y agoYes but the question is did it increase your productivity? If so, then why do you think it did?
- ntoshev 18y agoNobody knows a good way to measure this and you know it. Just because we can't measure it doesn't mean it is not real (I'm not claiming either way).
- arebop 18y agoRight. I was tempted to say that our pace was somewhat reduced (not to 50%), and our code was greatly improved, because that was our impression. We did not adjust old estimates to account in any way for pairing, and we saw a trend toward improvement in |actual - estimated| costs. Then again, every feature/bug and programmer is different. We didn't have many old estimates for unfinished work. We didn't consciously account for pairing in new estimates, but we didn't have any sort of experimental rigor. The non-pairing programmers definitely wrote worse code, but they were the weaker programmers in the first place. Maybe our improved estimation accuracy was because our product was maturing. There are some reviewed papers covering experiments on pairing. Laurie Williams [http://collaboration.csc.ncsu.edu/laurie/ http://collaboration.csc.ncsu.edu/laurie/] is an author of many of them. Here's one not by her: http://portal.acm.org/citation.cfm?doid=1145293 http://portal.acm.org/citation.cfm?doid=1145293.