{"id":1741,"date":"2016-05-25T22:42:06","date_gmt":"2016-05-25T21:42:06","guid":{"rendered":"https:\/\/www.entropywins.wtf\/blog\/?p=1741"},"modified":"2018-07-31T13:02:06","modified_gmt":"2018-07-31T12:02:06","slug":"is-pair-programming-really-worth-it","status":"publish","type":"post","link":"https:\/\/www.entropywins.wtf\/blog\/2016\/05\/25\/is-pair-programming-really-worth-it\/","title":{"rendered":"Is Pair Programming worth it?"},"content":{"rendered":"

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.<\/p>\n

\"Extreme<\/a><\/p>\n

The cost of Pair Programming<\/h2>\n

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<\/strong> for the same output. In other words, the development cost is multiplied by two.<\/p>\n

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<\/strong>. An article on c2 wiki<\/a> suggests 10-15% more total developer time, with the time elapsed being about 55% compared to solo development.<\/p>\n

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.<\/p>\n

The cost of not Pair Programming<\/h2>\n

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<\/strong>. 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<\/strong>. With dedicated review, the reviewer will often have a hard time understanding all the relevant context and intent<\/strong>. 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<\/strong>. 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.<\/p>\n

\n

Pair Programming is not a “go faster” strategy, it is a “waste less” strategy (which often results in going faster)<\/p>\n

\u2014 Kent Beck (@KentBeck) February 12, 2015<\/a><\/p><\/blockquote>\n