Live data from Hacker News

Ask HN: How useful is Pair Programming?

news.ycombinator.com

21–26 of 26 posts

Re: Ask HN: How useful is Pair Programming?

#22
post #18

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-te…

> 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.

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.

Re: Ask HN: How useful is Pair Programming?

#23
post #18

Earlier quoted context omitted.

> 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.

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 p…

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 :)

Re: Ask HN: How useful is Pair Programming?

#24
post #23

Earlier quoted context omitted.

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 p…

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 :)

Yep, unfortunately http://martinfowler.com/bliki/CannotMeasureProductivity.html

Re: Ask HN: How useful is Pair Programming?

#25
post #16

Three words: Pair as needed.

Couldn't agree more. Any set of talented developers in an open environment will naturally pair when one or the other has a critical piece of code to write or some code they want input on. The key is getting the right sort of developers who know when they are stuck, and a no-blame environment where you can be called on bad code decisions.

Trying to mandate this sort of sharing through policies strikes me as ridiculous and the sort of thing that drives good developers out. Training a junior is one thing, having them assigned to 'help' is something entirely different.

I've always thought of pair programming as something that consultancy firms dreamed up to charge clients twice as much for the same amount of work. Perhaps I'm just cynical and tainted as it was a highly-paid consultancy firm that first tried to sell me on the idea.

Post reply on HN