Ask HN: How useful is Pair Programming?
25 comments
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.
* 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.
> 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.
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.
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
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.
Microsoft 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.
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.
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
Pair-programming as a dogmatic part of the development process is, IMNSHO, very overrated.
Coding standards, simple interfaces, commit policies, etc are far more important.
Pair programming is useful for,
* Building small but critical pieces of code which everyone interfaces with on some level inside a group (a core plugin API would be a good example)
* Knowledge transfer. I use PP extensively to work-in new people and get them comfortable with a codebase, svn commit policy, documentation, etc. (I let them choose the tools, read on for more on that).
* Solving short coding problems in a common piece of code.
Code review also plays a much more important role than PP. The ability to read, understand and change each others code should just be built into the development process instead of trying to force an artificial level of quality/shared-knowledge via PP.
As an example, in my spare time I'm implementing a simple and clean Ruby version of some core functionality that we have in C# and JS (yes, I know, odd combination). A colleague is tracking my commits and implementing the same system in Python (also in his spare time). At any point in the future, someone wanting to implement this in Perl (for example) can just follow the commit changes on this reference implementation.
PP is also tricky when you choose to do something other than C# or Java, because in those cases you have a common IDE that's used in the company.
If you're doing anything unix-y some people will use emacs (setup their way) and others screen + vim (setup their way). Some poor misguided fools will use Notepad++ on Windows, and while that's fair enough if it works for them, that doesn't help matters any for PP.
I'm not dismissing PP, but the XP model just isn't suited for every environment.
Coding standards, simple interfaces, commit policies, etc are far more important.
Pair programming is useful for,
* Building small but critical pieces of code which everyone interfaces with on some level inside a group (a core plugin API would be a good example)
* Knowledge transfer. I use PP extensively to work-in new people and get them comfortable with a codebase, svn commit policy, documentation, etc. (I let them choose the tools, read on for more on that).
* Solving short coding problems in a common piece of code.
Code review also plays a much more important role than PP. The ability to read, understand and change each others code should just be built into the development process instead of trying to force an artificial level of quality/shared-knowledge via PP.
As an example, in my spare time I'm implementing a simple and clean Ruby version of some core functionality that we have in C# and JS (yes, I know, odd combination). A colleague is tracking my commits and implementing the same system in Python (also in his spare time). At any point in the future, someone wanting to implement this in Perl (for example) can just follow the commit changes on this reference implementation.
PP is also tricky when you choose to do something other than C# or Java, because in those cases you have a common IDE that's used in the company.
If you're doing anything unix-y some people will use emacs (setup their way) and others screen + vim (setup their way). Some poor misguided fools will use Notepad++ on Windows, and while that's fair enough if it works for them, that doesn't help matters any for PP.
I'm not dismissing PP, but the XP model just isn't suited for every environment.
From what I've seen, this is something with a lot of hype. I've seen a lot of smoke, but little fire.
Anecdotally, I've heard and seen that it helps, and that it hurts. I've seen people praise it as the answer to all productivity problems (along with TDD and ATDD, of course) and I've seen people curse it.
My opinion? It's good for leveling out the programmers on a team. If I had 6-8 team members I might have one pair going at all times -- usually the pairing up a weak/new developer with somebody who can help him. But I wouldn't expect productivity improvements -- I'd simply use it as a way of level-setting the team. It seems like a good mechanism for bringing people up to speed quickly.
Having said that, you have to let the team be the judge. If they like it, do more of it. If not, don't. Whatever you do, don't let hype and religion get in the way of the team performing. Life is too short to make it miserable by doing something everybody thinks is stupid.
Some of the TDD guys are doing ping-pong pair programming. That's where person A writes a test for new code, then person B writes code for the test and then writes a new test for new functionality. It bounces back to person A, who writes the new functionality and then a new test for new stuff, etc.
That at least seems more interesting for folks.
Personally, I don't like it. But I try to be open-minded about it (especially since I teach this stuff!)
Be aware that in some anal-retentive shops, pair programming is a security violation. (You're not supposed to be sharing your terminal session with anyone)
Anecdotally, I've heard and seen that it helps, and that it hurts. I've seen people praise it as the answer to all productivity problems (along with TDD and ATDD, of course) and I've seen people curse it.
My opinion? It's good for leveling out the programmers on a team. If I had 6-8 team members I might have one pair going at all times -- usually the pairing up a weak/new developer with somebody who can help him. But I wouldn't expect productivity improvements -- I'd simply use it as a way of level-setting the team. It seems like a good mechanism for bringing people up to speed quickly.
Having said that, you have to let the team be the judge. If they like it, do more of it. If not, don't. Whatever you do, don't let hype and religion get in the way of the team performing. Life is too short to make it miserable by doing something everybody thinks is stupid.
Some of the TDD guys are doing ping-pong pair programming. That's where person A writes a test for new code, then person B writes code for the test and then writes a new test for new functionality. It bounces back to person A, who writes the new functionality and then a new test for new stuff, etc.
That at least seems more interesting for folks.
Personally, I don't like it. But I try to be open-minded about it (especially since I teach this stuff!)
Be aware that in some anal-retentive shops, pair programming is a security violation. (You're not supposed to be sharing your terminal session with anyone)
Almost all of the methodology promoted as "Pair Programming" is at best neutral, but there is a kernel of awesomeness in the idea:
Get two developers working in close proximity, criticizing with each other constantly as they work. The more yelling the better.
Get two developers working in close proximity, criticizing with each other constantly as they work. The more yelling the better.
The 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.
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.
I've read that pair programming is good for mediocre or novice programmers.
Citation?
There's both sides of pair programming... recently I attended a presentation where the presenter basically said that pair programming should be mandatory... on the other hand, I've done pair (and even triplet) programming... Here's my thoughts:
* Advantages - Works great in initiating a new team member in to a large project - Gives each developer a chance to do code-review on the fly - If there's good rapport, pair programming can get a lot more done
* Issues - Requires good co-ordination between team members - Two similar thinking people may not be able to take full advantage of this technique
* Advantages - Works great in initiating a new team member in to a large project - Gives each developer a chance to do code-review on the fly - If there's good rapport, pair programming can get a lot more done
* Issues - Requires good co-ordination between team members - Two similar thinking people may not be able to take full advantage of this technique
The fact is that very few studies have actually been done so most of what you get are anecdotal accounts.
I think pair programming has it's uses, for example, when a developer is stuck on a problem and can't move forward it's often helpful to have another set of eyeballs, but I have yet to see it effectively used full time (except for consultants who get to bill out at a double rate!).
A good book to check out with some counter arguments to pair programming and XP in general is "Extreme Programming Refactored: The Case Against XP".
A good book to check out with some counter arguments to pair programming and XP in general is "Extreme Programming Refactored: The Case Against XP".
In 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.
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.
_very_ useful, but not exclusively. pairing is great for gaining momentum, learning a new technique or domain, focusing on solving a particularly hard problem and mentally syncing with your co-prorammer. it is draining and ineffective if done for more than a week or two.
If 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.
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.
This was discussed on HN recently. Lots of good comments here:
http://news.ycombinator.com/item?id=490173
http://news.ycombinator.com/item?id=490173
Ah.. Thanks for the link. I missed that during my vacation..
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.
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.
What are the advantages and disadvantages? Statistical data/study would help.