Updated on February 22, 2018
Is Pair Programming worth it?
Every now and then I get asked how to convince ones team members that Pair Programming is worthwhile. Often the person asking, or people I did pair programming with, while obviously enthusiastic about the practice, and willing to give it plenty of chance, are themselves not really convinced that it actually is worth the time. In this short post I share how I look at it, in the hope it is useful to you personally, and in convincing others.
The cost of Pair Programming
Suppose you are new to the practice and doing it very badly. You have one person hogging the keyboard and not sharing their thoughts, with the other paying more attention to twitter than to the development work. In this case you basically spend twice the time for the same output. In other words, the development cost is multiplied by two.
Personally I find it tempting to think about Pair Programming as doubling the cost, even though I know better. How much more total developer time you need is unclear, and really depends on the task. The more complex the task, the less overhead Pair Programming will cause. What is clear, is that when your execution of the practice is not pathologically bad, and when the task is more complicated than something you could trivially automate, the cost multiplication is well below two. An article on c2 wiki suggests 10-15% more total developer time, with the time elapsed being about 55% compared to solo development.
If these are all the cost implications you think about with regards to Pair Programming, it’s easy to see how you will have a hard time to justify it. Let’s look at what makes the practice actually worthwhile.
The cost of not Pair Programming
If you do Pair Programming, you do not need a dedicated code review step. This is because Pair Programming is a continuous application of review. Not only do you not have to put time into a dedicated review step, the quality of the review goes up, as communication is much easier. The involved feedback loops are shortened. With dedicated review, the reviewer will often have a hard time understanding all the relevant context and intent. Questions get asked and issues get pointed out. Some time later the author of the change, who in the meanwhile has been working on something else, needs to get back to the reviewer, presumably forcing two mental context switches. When you are used to such a process, it becomes easy to become blind to this kind of waste when not paying deliberate attention to it. Pair Programming eliminates this waste.
Pair Programming is not a “go faster” strategy, it is a “waste less” strategy (which often results in going faster)
— Kent Beck (@KentBeck) February 12, 2015
The shorter feedback loops and enhanced documentation also help you with design questions. You have a fellow developer sitting next to you who you can bounce ideas off and they are even up to speed with what you are doing. How great is that? Pair Programming can be a lot of fun.
The above two points make Pair Programming pay more than for itself in my opinion, though it offers a number of additional benefits. You gain true collective ownership, and build shared commitment. There is knowledge transfer and Pair Programming is an excellent way of onboarding new developers. You gain higher quality, both internal in the form of better design, and external, in the form of fewer defects. While those benefits are easy to state, they are by no means insignificant, and deserve thorough consideration.
Give Pair Programming a try
As with most practices there is a reasonable learning curve, which will slow you down at first. Such investments are needed to become a better programmer and contribute more to your team.
Many programmers are more introverted and find the notion of having to pair program rather daunting. My advice when starting is to begin with short sessions. Find a colleague you get along with reasonably well and sit down together for an hour. Don’t focus too much on how much you got done. Rather than setting some performance goal with an arbitrary deadline, focus on creating a habit such as doing one hour of Pair Programming every two days. You will automatically get better at it over time.
If you are looking for instructions on how to Pair Program, there is plenty of google-able material out there. You can start by reading the Wikipedia page. I recommend paying particular attention to the listed non-performance indicators. There are also many videos, be it conference tasks, or dedicated explanations of the basics.
My own experience
I am a big believer in leading by example. Why would you follow advice if the person dispensing it does not follow it themselves? Hence I feel that I should address why I myself do nearly all of my programming work “on my own”.
There is a cost beyond the ones mentioned so far, at least for some people. I already alluded to it by mentioning introversion. Personally I am quite introverted and prefer to not have more than two hours of active engagement with people per day. If the day already contains meetings or personal activities of certain kinds, not much extroversion is left for Pair Programming.
As much as I like habits as a powerful way to save willpower and make things happen, I can’t follow my own advice here either. This due to me having an unusual sleeping schedule, which prevents planning of recurring meetings with colleagues.
Pair Programming sits at or near the logical extreme of things such as knowledge sharing and short feedback loops. Hence when not Pair Programming it becomes all the more important to pay attention to those.
I’m a big fan of creating small commits and having them reviewed fast and I like briefly talking to a colleague about a task before starting on it, both as a sanity check and to steal their good ideas. Likewise I like talking to a colleague when I run into a scenario where the solution is not so obvious or the trade-offs are not that clear. All of this helps with getting feedback quickly. Another thing I really like is leaving work in a state that colleagues can continue with it, and encouraging people to continue with work their colleagues started. This creates collective ownership and collective understanding of the code.
So if for whatever reason you do not do Pair Programming, you can still benefit from keeping in mind the benefits it provides and trying to approach these in other manners. Have a look at this list of Best Practices for inspiration. And better yet, even if you are introverted, at least give Pair Programming a try!