When doing software development there are many choices that can affect your productivity. There are choices about how a company works. One of those is doing pair-programming over doing solo-programming. We recently had a consultant at our company who claimed that pair-programming is proven to be better but who couldn't point to evidence.
How does the case for pair-programming look like? What do we know? How can we rationally think about the question?
I found a 2008 meta-analysis. https://www.idi.ntnu.no/grupper/su/publ/ebse/R11-pairprog-hannay-ist09.pdf
From the conclusion:
Our meta-analysis suggests that pair programming is not uniformly beneficial or effective, that inter-study variance is high, and that perhaps publication bias is an issue. ... However, with respect to the central factors expertise and task complexity, the current state of knowledge suggest that pair programming is beneficial for achieving correctness on highly complex programming tasks. Pair programming may also have a time gain on simpler tasks. By cooperating, programmers may complete tasks and attain goals that would be difficult or impossible if they worked individually. Junior pair programmers, for example, seem able to achieve approximately the same level of correctness in about the same amount of time (duration) as senior individuals. However, the higher quality for complex tasks comes at a price of a considerably higher effort (cost), while the reduced completion time for the simpler tasks comes at a price of a noticeably lower quality.
By personal subjective experience, the usecase where pair programming shines most is onboarding and skill transfer. Basically, you have a person who needs to learn a skill and a person who has the skill, so you sit the person who has the skill next to the other person and get the other person to do a task that needs the skill by instruction of the person who has the skill. This is way more efficient than lectures and slightly more efficient than reading documentation, because all parts of the skill are taught, only relevant information is taught, and the instruction is necessarily in actionable form. Important conditions are that the learning person is open to instruction and correction, and the teaching person avoids meandering into irrelevant information. Pair programming done like this relies on both parties being effective communicators.
(A related technique is mob programming, which is useful for collaborative design assuming your code environment is highlevel enough to keep pace with the discussion.)
I don't think pair programming is ever *strictly* better than solo programming, but I have found it to be a great way to help teach skills that are hard to describe algorithmically:
Some specific cases:
A non-obvious one:
I found pair programming pretty useful when starting a new project from scratch, when changes are likely to be interdependent. It is then better to work with, let's say, 1.5x the performance of a single developer on one thing a time, than to work separately and then try to reconcile the changes. Knowledge transfer is also very important at this stage (you get more people with the same vision of the fundamentals).
This generalizes to other cases when there is a "narrow front" - when few things can be worked on in parallel without stepping on each other's toes.
Even more generally, it seems there are three kinds of clear benefits:
1) Less change synchronization (fewer changes worked on at the time).
2) Knowledge transfer (see @FeepingCreature's answer).
3) Immediate, detailed review - probably fewer defects.
There is also a matter of raw throughput (or how much time is required to make a specific change, while the rest of the code is assumed to stay the same, ignoring the cost of syncing with any changes done in parallel). A naive baseline is that a pair has a throughput of a single developer (since they're working on one change at a time). Fortunately, it can be way better, because one person can just focus on the details on the code and the other on the slightly bigger picture and next steps, look up the relevant facts from the documentation etc. This eliminates a lot of context switching and limits the number of things that each developer needs to keep in working memory. Also a lot of typos and other simple problems get caught immediately, so there is less debugging to do. It's not so clear, what all of this stuff adds up to.
I was able to find some studies about the topic, including a meta-analysis by Hannay et al. TL;DR: it depends on the situation, including how experienced are the developers and how complex is the task). It's clearly not a silver bullet and generally it still seems to be a trade-off between person-hours spent and the quality of the produced software.
I've had experiences ranging from "great" to "terrible" when pairing. It's worked best for me when I'm paired with someone whose skills are complementary to mine. Concretely: I'm very much about rigour, type-safety, correctness; the person I have in mind here is a wizard at intuiting algorithms. The combination worked extremely well: the pairer generated algorithms, and I (at the keyboard) cast them into safe/correct forms.
However, when paired with someone who eclipses me in almost every dimension, I ended up feeling a bit bad that I was simply slowing us down; and conversely I've also experienced pairing with someone who I didn't feel was adding much to the enterprise, and it felt like I was coding through treacle (because the thoughts had to flow out to another person, rather than into the compiler).
In my experience, good pairs are really good, but also quite rare. You're looking for a certain kind of compatibility.
To answer your actual question: just try it! It's cheap to try, and you can find out very quickly if a certain pairing is not for you. (I would certainly start the exercise by making sure both parties know that "this pair isn't working out" is not a judgement on either party.)
One thing I feel strongly about is that pair-programming is a skill, and that if both participants aren't skilled at it, things will be rough. When I was at my coding bootcamp, they'd always separate us into pairs and have us pair program on the exercises they'd give us. It was terrible. The driver would always just go off on their own.
My experience with pair programming has been mostly positive. I've taken both roles, but more often as the navigator.
Incentives in school are different than at a real company: Individual grades vs the success of the company that's paying your salary; getting along with people you may never see again after this semester vs approval of peers you may be working with for years. Also, the kind of people in a coding bootcamp are not necessarily the kind of people who would actually get hired to do programming.
Junior/senior pairings seem to work best when the senior is navigating and the junior is driving. Yes, it helps if the senior is patient and the junior is willing, but the junior is not particularly skilled at programming generally.
Found a long dissertation on the topic: https://collaboration.csc.ncsu.edu/laurie/Papers/dissertation.pdf
From the abstract:
- Collaborative pairs spend approximately 15% more time than do individuals on the same task. This additional time, however, is not statistically significant.
- Collaborative pairs achieve a higher quality level for programming products. Pairs had 15% less defects in their code. The higher quality level is statistically significant.
- Considering the long-term field support savings of higher quality programming products, collaborative programming is cheaper for an organization than individual programming.
- Consistently, 95% of collaborative programmers asserted that they enjoy their work more and are more confident in their work than when they pro-gram alone.
The abstract also mentioned enhanced skills and teamwork as benefits.
It's easy to play armchair statistician and contribute little, but I want to point out that the empirics cited here are effectively just anecdotes. The paper studies 13 pairs and 13 individuals in three assignments in one class at UUtah. Its estimate of relative time costs is only significant to ~ because development time has variance of (if I backsolved correctly) 65%, which...seems about right. Still, it seems like borderline abuse of frequentist statistics to argue that a two-tailed p<0.05 should be required to reject the hypothesis that pairs finish projects in half the wall-clock time of individuals (which is the null the analysis assumes).
That said, the author correctly identifies that quality matters significantly more than speed. The quality metric, however, is "assignment tests passed" in throwaway academic projects, eliding the questions of what quality failures would or wouldn't be caught by the review / CI workflows that an industrial project would be going through anyway.
So, finger to the wind, this study feels like it suggests that a pair spends 15% more person-hours (once they get used to each other) before turning their schoolwork in, and do 15% more of the work of the assignment than a student working alone. Consistent with the higher reported work-enjoyment numbers! Definitely a stronger showing than I would have guessed! But definitely not well-abstracted by "no significant result for time; significant improvement for quality".
What am I missing here?
I only had one experience with pair programming, and it was a positive one. Both in terms of emotional satisfaction, and productivity.
But I suspect that it is a pleasant experience when you are paired with a person you would otherwise enjoy talking to about programming. Because that's more or less what it is, except you are also producing the code you talk about.
If I had to pair-program with a person I don't "click" with -- either because of personality, or because of wildly different opinions on what is the desirable way to write code -- I can imagine it could become a form of torture. (But that's just a guess; I didn't have an opportunity to try.)
For this reason, I imagine the answer to whether "pair-programming is better" would depend on many things. How compatible are the team members? Are you allowed to choose your pair, or do you get one assigned against your will? (What happens when one member of the pair takes a vacation?)
But talking openly about personal compatibility is something I can hardly imagine in a workplace. I mean, jobs are usually hierarchical, hierarchical environment is antithetical to sincerity, expressing your true feelings could be taken as unprofessional behavior; so you could get people reporting that they "click" with everyone (or everyone high-status) just because they want to be seen as "team players", or because they want to be paired with someone highly productive so that their pair productivity will also be high.
In summary, I imagine the proper research would need to take personal compatibility into account, but there are incentives to provide wrong information. The research would have to address this.
I had a pair programming experience at my first job back in the late 80s, before it was a thing, and my coworker and I clicked well, so it was fun while it lasted. Never had a chance to do it again, but miss it a lot. Wish I could work at a place where this is practiced.
One thing I feel strongly about is that pair-programming is a skill, and that if both participants aren't skilled at it, things will be rough. When I was at my coding bootcamp, they'd always separate us into pairs and have us pair program on the exercises they'd give us. It was terrible. The driver would always just go off on their own.
My experience with pair programming has been mostly positive. I've taken both roles, but more often as the navigator.
Incentives in school are different than at a real company: Individual grades vs the success of the company that's paying your salary; getting along with people you may never see again after this semester vs approval of peers you may be working with for years. Also, the kind of people in a coding bootcamp are not necessarily the kind of people who would actually get hired to do programming.
Junior/senior pairings seem to work best when the sen
... (read more)