So, every so often, you hear someone suggesting introducing a weird dev practice – pair programming. You ask yourself – why would I ever pay TWO people doing the work of one person? It’s closer to 10%. There are numerous benefits in areas of software quality and team dynamics, as well as challenges. For more info, I suggest reading this great article by Martin Fowler. This article will deal with the economics side of the practice, so let’s dive into it.
Developers are scarce so it’s not easy to accept anything that would dilute the productivity. However, while my team has been using the practice, I didn’t notice any significant drop. It was a bit counter-intuitive, so I compared the workday of two individual developers with two that work in pairs. Agile-based frameworks introduce overhead that reduces the total productivity, with or without pair programming. From my experience, it’s about 15%.
When people work in pairs they are more focused on the work in front of them. Some reports say that about 28% of the time the average worker spends reading the e-mail. I don’t think that’s true in IT. When you factor in other kinds of business-related interruptions (instant messaging, questions by teammates, etc.), it’s significant. I estimate it at ~30%. While a pair certainly gets interrupted, it’s less likely and often structured in time slots that prevent focus dilution. Considering you need about 23 minutes to regain focus, savings from the reduced interruptions are significant, at least a half. It’s just harder to interrupt a pair.
Let’s add it all up. Two people working on two separate tasks will have about 60 units of productivity out of 200. Two people working on the same task will have effective 55 units of productivity. That means two people will do about 10% more when they work separately than when they work together. A paper I have found says the number is about 15%, which is similar to the numbers I have.
Keep in mind that a person working on its own is not only 30% productive. Agile overhead is also a productive time (and often tracked separately), so is most of the interruptions. Agile coaches suggest the actual productivity time is about 65%, but that’s a topic for another time.
So, the next time a team suggests implementing the pair programming practice, remember that it’s not as expensive as you’d think.