3 ms·
> we'll have less technical debt due to pairing. Could you explain this point? I think most of the points you make a pretty good points. I have not worked in
by aj 18y ago
> we'll have less technical debt due to pairing.
Could you explain this point?
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.
- Edinburger 18y agoSure - 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.
- aj 18y agoAh.. 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 :)
- Edinburger 18y agoYep, unfortunately http://martinfowler.com/bliki/CannotMeasureProductivity.html http://martinfowler.com/bliki/CannotMeasureProductivity.html