You walk around your office and you see that most developers are sitting by themselves, doing their work. You finally spot a group of two developers working together on the same task on the same computer. In other words, they are pair programming. You stop and think to yourself-we have two people doing work that could be done by one person; wouldn’t it be more efficient if we split these people up? Let’s first take a look at the benefits of pair programming to see why someone might consider doing pair programming. After that, we will look at some of the common arguments used against pair programming to see if pair programming is still worth it or not.
Dr. Laurie Williams performed a study in 2000 with her class of 20 students to analyze the costs of pair programming.1 She had 1/3 of her students do a programming assignment by themselves and 2/3 of her students do the same programming assignment in pairs. The work done in pairs resulted in 15% fewer defects. These results were statistically significant. She believes that the reduction in defects is attributed to pairs considering more design alternatives, resulting in a more simple design.
Pair programming has the additional benefit of knowledge transfer.2 Almost every time I pair program with someone, I learn at least one cool keyboard shortcut or way of using a tool that I was not aware of. Whenever I am learning a new technology, I like to pair with someone who is already familiar with that technology. I will learn significantly faster this way than working on my own. You will also be surprised how often an expert still learns when being paired with a novice. One of the most important questions to ask at the end of the year is how much you improved in the past 365 days. If you did pair programming, you will have improved more than if you did not do pair programming. It is pretty cool to think that using pair programming would help you improve more from year to year than not pair programming.
It is natural to have some tasks depend on each other when planning.3 These dependencies make it harder to plan work because work has to be done in a certain order. There is always the chance of someone getting blocked in the middle of the sprint because their next task depends on something that another teammate is doing. With pair programming, we divide the amount of work in progress by two, making it less likely that someone will be blocked. Imagine you have four developers that are not pair programming. You have to have four tasks in progress at a time. It could be the case that there are four tasks remaining in the sprint but one of them depends on another task. Without being allowed to pair, the fourth developer would have to start working on a task that is not in the sprint because he or she is otherwise blocked with nothing to do. With pair programming, the team would only need two tasks in progress at a time so even if one of the four tasks is blocked, each developer can still work on tasks during the sprint. Having less work in progress also makes it easier to understand what is being worked on at any given point in time.
Imagine that you are working on a task by yourself and at the start of the task, you make an assumption about how things work. Lets say that the work you do for your task depends on this assumption. Furthermore, lets say that this assumption is wrong but you are not aware of it. After typing up 1,000 lines of code, you upload your code to be reviewed. A teammate of yours observes that you made an incorrect assumption and now this 1,000 lines of code needs to be completely re-written. This is very inefficient. We can improve our efficiency by shortening the feedback loop. You start working on your next task by yourself and this time you upload a code review after 200 lines of code. If it turns out you made an incorrect assumption early on when doing your task, there is less code that has to get tossed. Now, imagine you are pair programming your next task. You make an incorrect assumption but your partner immediately catches the mistake before you even write another line of code. Thus you can see how pair programming decreases the amount of code that you will write that has to get thrown away.
There is a non-linear relationship between the number of branches and integration problems.4 This means that cutting the number of branches in half with pair programming will make integration more than twice as easy. Thus, the more teammates there are, the more important it is to pair program. Not only that, but there will be significantly less merge conflicts. You might think that having people pair program will cut merge conflicts in half. That is not the case. It will actually reduce merge conflicts by more than that. Imagine two developers that are not pair programming. Any developer might have a merge conflict with one other branch. Now imagine that these two developers pair program. They will not have any merge conflicts! Lets visualize this for four developers who are not pair programming. Any of these developers could have merge conflicts with three other branches. Now imagine that these four developers pair program. They could only have merge conflicts with one other branch!
Many people have a hard time believing that having two people sitting at a computer can possibly be more efficient than having each person work on a task by themself. In the previously referenced study1 done by Dr. Laurie Williams, man hours and elapsed time were also measured. Even though work done in pairs took less elapsed time to complete the assignment, it took 15% more man hours. However, Laurie argues that this 15% increase in initial cost is more than offset by the 15% reduction of defects since fixing a defect earlier is significantly cheaper than fixing it later. She also states that if the code is sent to a testing organization prior to being released, it could take up to 15 times more man hours to fix the defects that resulted from not pair programming than the additional hours that would have been spent not producing those defects by pair programming. If the product is sent directly to the customer instead of a testing organization, pair programming is even more favorable. Industry data suggests that 33-88 hours are spent on each defect found in production while only 4-16 hours are spent on fixing defects at a testing organization.5
Dr. Laurie Williams continued to write a book two years later and concluded that pair programming reduces cycle time.6 How is it that pair programming reduces cycle time when earlier research1 concluded that pair programming takes 15% more man hours? There is an issue with the earlier study1 that should be known. This study just had students pair program for one assignment, which did not cause much of the other benefits of pair programming to be seen. The knowledge transfer gained from pair programming would make future assignments done faster but no future assignments were done so this benefit was not seen. The easier planning benefit was not seen since this was for one assignment instead of a collection of tasks which is what is seen in scrum with larger teams. The less merge conflicts benefit was not seen because college students only ever work in one branch anyway (you can trust me on this). We also know that pair programming results in you having coded up a higher percentage of a project which will give you a better understanding of the project. This would speed up future tasks on the project but as we stated earlier, this experiment just involved one assignment. So while tasks will take more man hours initially when pair programming, the tasks will have overall taken less hours from pair programming by the time you are ready to release. You can think of pair programming as something that slows you down in the short run but speeds you up in the long run due to the knowledge transfer and increased understanding of the project.
Another common argument a person might make against pair programming is that they prefer to work independently and don’t like having to work with a partner. It is most likely the case that a developer who has not pair programmed before will be skeptical to the idea of pair programming.6 However, statistically significant results concluded that developers who had previously coded alone reported that they enjoyed pair programming more than coding alone.1 In fact, before I pair programmed, I did not predict that it would be more enjoyable than programming alone. After I bit the bullet and tried out pair programming, I liked it more than not pair programming. In fact, my whole team likes pair programming now. Despite the fact that most developers who have done pair programming have reported that pair programming is more fun than programming alone, there will still be developers who try pair programming and don’t find it as fun as programming alone.
So is pair programming worth it? It may appear that the answer from me is going to be a resounding yes. In fact, I have seen many books that have also argued in favor of incorporating pair programming2,3,4,6,7,8,9,10,11,12 and none that have completely opposed pair programming. However, lets close by considering three scenarios:
1) A team pair programs and is passionate about pair programming
2) A team pair programs but is not passionate about pair programming
3) A team does not pair program
I would argue that scenario 1 is the best by far. We have seen many benefits from pair programming and even a reduced cycle time and reduced cost so it is hard to argue against pair programming unless people just happen to not enjoy it. Pair Programming Illuminated6 argues that attempting to force a team to pair program is the wrong idea. If a team just isn’t passionate about pair programming, their output will be worse than not doing pair programming at all. As a result, scenario 2 is the worst scenario. I think that any team that has never pair programmed before should give it a try, even if they predict they won’t like it. Pair programming is one of those things that most people predict they won’t like it but then turn around liking it after they try it out for the first time. If a team tries out pair programming and still does not enjoy it after 2-4 weeks, then they should stop pair programming and never do it again.
So what if our team does do pair programming? Would we pair program every task? Should we pair experts with experts, novices with experts, novices with novices, or a little of each? How frequently should we rotate pairs? We will explore the answers to these questions in a future blog post.