Pair programming is useful when the project is so heinous and boring that nobody would work on it unless there's another person sitting next to them keeping them on task.
I think you just described my entire CS undergrad experience.
Ask HN: How useful is Pair Programming?
11–20 of 26 posts
Re: Ask HN: How useful is Pair Programming?
#12Microsoft did an internal study you might find interesting:
http://research.microsoft.com/en-us/um/people/abegel/papers/...
I also know that they sponsored research by the Stanford CS department where they gave pairs and individuals the same programming task (completable in an afternoon), but I have no idea what the results of that were or if they were ever published.
My personal experience is pretty analogous to other people's: it causes you to work more slowly and carefully, it's good for knowledge transfer, and some people are better suited for it (personality-wise) than others. I find it most effective when avoiding errors or technical debt is imperative or when you want to transfer knowledge, and not as useful otherwise.
I've also noticed that my perceived productivity is lower when pairing than it actually is; I'm so used to cranking by myself that slowing down so someone else can talk with me about what to do, or being the "navigator" and not coding at all, makes me feel like I'm not getting anything done. In reality, though, I'm actually getting a fairly decent amount done, and more importantly we're probably avoiding mistakes or blind alleys that would have cost me time in the long run. That makes it hard to measure the real productivity difference: if two people had coded by themselves for 8 hours, more "work" would have been done than if those two people paired for 8 hours, but how much of that would have been wrong, or unnecessary, or overly-complicated, or introduced more technical debt?
It's the sort of skill that takes work, and that gets easier as you do it, so I'd encourage you to try it out. As with any new way of working, it'll be awkward at first and then get easier, and I think it's worth at least learning so that in the future you'll be able to judge for yourself when you feel like pairing will be most useful and when you're better off flying solo.
Re: Ask HN: How useful is Pair Programming?
#13In my experience, pair programming is to programming what eating less and exercising is to obesity: most people simply can't bring themselves to do it, even after trying it and experiencing success. My advice is to just forget about it, like doctors these days who prescribe drugs for cholesterol and high blood pressure without even bothering to mention that those conditions can usually be controlled via lifestyle changes. Unless you're really lucky, you won't find anybody else willing to practice it with you.
If you actually get a chance to introduce pair programming to your organization, go for it. In my unfortunately limited experience, pair programming paid for itself by virtually eliminating some classes of mistakes. Typos and other oversights are caught faster and more efficiently, of course, but more importantly, things that lone programmers tend to put off figuring out, the mental and sometimes subconscious TODOs, get hashed out immediately. That saves time rewriting bad designs.
Unfortunately, as with lifestyle change, people start enthusiastically but quickly sour on it until the mere mention of it evokes anger and resentment.
Re: Ask HN: How useful is Pair Programming?
#14This was discussed on HN recently. Lots of good comments here:
Re: Ask HN: How useful is Pair Programming?
#15If you have access to trade journal type archives (IEEE, ACM, etc) you can find a lot of articles/studies on pair programming. Most of those that I've seen tend to be positive in their attitude toward pairing, though it's sometimes hard to tell if bias is at work there; also, many are in an academic setting environment rather than a corporate or startup/consulting environment, which may lead to some different results.
If you're a student, or know one, it's very probable that your school's library might have online access to some of these journals. If you want statistics, that might be a good place to start.
Re: Ask HN: How useful is Pair Programming?
#16Three words: Pair as needed.
Re: Ask HN: How useful is Pair Programming?
#17The bloke in my next cubicle practices it and I hate it!
All day long they are always discussing where to put an if condition, assert or what to name their variables. And fuck I cannot concentrate.
Re: Ask HN: How useful is Pair Programming?
#18I'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.
Re: Ask HN: How useful is Pair Programming?
#19Pair programming is useful when the project is so heinous and boring that nobody would work on it unless there's another person sitting next to them keeping them on task.
But what about when it is interesting but only say more technically challenging than grunt work?
Re: Ask HN: How useful is Pair Programming?
#20Microsoft did an internal study you might find interesting: http://research.microsoft.com/en-us/um/people/abegel/papers/... I also know that they sponsored research by the Stanford CS department where they gave pairs and individuals the same programming task (completable in an afternoon), but I have no idea what the results of that were or if they were ever published. My personal experience is pretty analogous to oth…
I think that is the most fuzzy part. Determining combined productivity, factoring the "improved" quality and the knowledge sharing and gain is a lot more difficult than simply adding up the individual productivity of each programmer (whatever may the metric for measuring the productivity be), but in this case, not tending to factor in improved code quality, constant code review and higher probability of catching subtle bugs