A Dollar Value On Pair Programming

Posted by Mike Bria on Jun 24, 2009

Sections

Process & Practices,

Architecture & Design,

Development

Topics

Java ,

Delivering Quality ,

Removing Waste ,

Ruby ,

.NET ,

Agile

Tags

Pair Programming

"Why in the world would we use two people to do the job of one?" This is often the initial reaction to people when first introduced to the idea of pair programming. In essence, they perceive pair programming as doubling the cost of writing any segment of code. Dave Nicollete offers some quantitive ideas to help show how pair programming can save money, not waste it.

The economic value proposition of pair programming is most often misunderstood as a result of a misperception that programming is mostly about typing. In reality, of course, the majority of programming is really about thinking, and as a result provides endless opportunities to make bad decisions and create errors - errors that will ultimately cost developers (and thus the organization) time in the future.

This is where the economic value proposition of pair programming is founded, and also why it is hard to quantify. As Dave Nicolette summarizes in a recent article:

The value of pairing comes in the form of very small course corrections that prevent errors from occurring in the first place. The course corrections are of such small scope and they occur so seamlessly within the pair's work flow that they are usually not noticed at all...The value is easy to overlook because the effect of pairing is to prevent situations that would have caused extra work at some future time...It's not easy to observe or quantify these effects after the fact, because the bad stuff never happens.

So, the value of pairing comes in the form of saved future time, and, afterall, "time is money". But, how much money? In this same article, Dave took a stab at presenting some ideas to answering this question.

During a recent pairing session, Dave kept track of how often one pair helped the other by catching a mistake as well the design-related discussions that occurred. Afterwards, they decided how much future time each of these things saved, then with this information went on to do some more calculations:

In one of his early books, Alistair Cockburn computed that the cost of an IT professional amounts to about $2.10 per minute...In our pairing session we had two mini design discussions that led to small refactorings. By our reckoning, that saved four hours of future code maintenance effort. That's worth about 2.1 x 120 = $252.00. There were 12 moments when one of us noticed a minor mistake. If those occurrences saved an average of 30 seconds debugging effort, then it was worth .5 x 2.1 x 12 = $12.60. In total, we saved the company $274.60 in 90 minutes' time, or an hourly saving rate of about $180.00.
...
The company has a small IT department with a total of about 40 developers working in several XP teams. If we assume the developers pair about 5 hours a day, then that's 20 pairs x 5 hours x 5 days per week = 500 pairing hours per week. Assuming a savings of $180 per hour per pair, that makes the average hard savings attributable to pairing $90,000 per week. If that rate of work is more-or-less constant throughout the year, and the teams work 50 weeks a year (it's in the United States, so vacation time is short), the company enjoys a savings of about $4.5 million per year specifically because its software development teams pair-program as a standard practice.

$4.5 million for this organization of only 40 developers. As Dave concedes, these are only rough calculations derived from only a single pairing session, so this is by no means scientific, but it does nonetheless demand consideration.

What do you think?

1. Back to top

   What about the cost of the pairing itself?

   by Amr Elssamadisy

   Ok, I follow that you caught about 275$, but at a price of 90 minutes of another developer's time. And, at 2.1$/minute that's about an extra $180 you are paying for the next developer. So the savings is closer to 90$ in the 90 minutes and $60 an hour.
   
   And that all depends greatly on the example given being generalizable....

   Reply

2. Back to top

   Re: What about the cost of the pairing itself?

   by Mike Bria

   True indeed, the numbers aren't "net savings". But, even at $60/hr, this org is still saving - to the tune of $1.5million, yes? I'll take it.
   
   
   
   I think what's most important from this isn't the exact numbers, but rather what's being examined. That we try to put some quantification around these generally abstract benefits is the real news, in my opinion.
   
   
   
   Cheers
   
   MB

   Reply

3. Back to top

   This assumes the developers actually work well together

   by Fred Smith

   Put two strong developers together who have different opinions and they'll spend more time arguing about the right solution than getting anything done. Not every developer is this way, but many are as evidenced by how many times code that works is re-written for no other reason that the developer using it didn't write it. Put a weak and strong developer together and you'll get a product is the same if the strong developer wrote it themselves. Pair programming is a great concept, but it seems to me that good design and code reviews are more realistic solution to improve production quality.

   Reply

4. Back to top

   Re: This assumes the developers actually work well together

   by Mike Bria

   Fred,
   
   
   
   Have you ever tried pair programming yourself?
   
   
   
   I myself made similar arguments of logic years ago prior to actually ever really understanding (well, experiencing) pairing.
   
   
   
   The reality is that when a team adopts pair programming and applies it with respect and a shared understanding of purpose and etiquette, in most healthy environments, literally none the suspicions you mention turn out to be true at all.
   
   
   
   As Dave implies, the value is not easy to justify quantitatively or logically (although I still do make an attempt here), you just need to see it work for yourself to really understand.
   
   
   
   Cheers
   
   MB

   Reply

5. Back to top

   Re: What about the cost of the pairing itself?

   by Mark Levison

   In addition to the cost of pairing Dave's math assumes that all these variables are independant and I don't think there. Far more useful than these conjectures is Laurie Williams and Alistair Cockburns Paper: collaboration.csc.ncsu.edu/laurie/Papers/XPSard... - they conclude a cost of about 15% but a gain of the standard benefits:
   
   · many mistakes get caught as they are being
   typed in rather than in QA test or in the field
   (continuous code reviews);
   · the end defect content is statistically lower
   (continuous code reviews);
   · the designs are better and code length shorter
   (ongoing brainstorming and pair relaying);
   · the team solves problems faster (pair
   relaying);
   · the people learn significantly more, about the
   system and about software development (lineof-
   sight learning);
   · the project ends up with multiple people
   understanding each piece of the system;
   · the people learn to work together and talk
   more often together, giving better information
   flow and team dynamics;
   · people enjoy their work more.

   Reply

6. Back to top

   Re: What about the cost of the pairing itself?

   by Mike Bria

   Very cool reference Mark. Does that paper make any statement about how much (quantitively) someone may expect to possibly gain from any of those benefits?

   Reply

7. Back to top

   Based on many implicit assumptions.

   by Amr Elssamadisy

   Ok, so first of all thanks Mike for the post and thanks Dave for the original blog!
   
   Now, this is all well and good in a conversation that we pro-Agilists have together. I'm afraid I couldn't make it hold water with a skeptical client.
   
   This is a construct that is based on several assumptions that we believe based on our anecdotal experience:
   
   1) The overall amount of functional code produced by a pair is comparable to that if they worked individually in parallel. (In fact I believe the paper Mark Levison cites above shows a 15% slow down when pairing.)
   
   2) That this piece of anecdotal evidence is the rule and not the exception.
   
   3) That the problems caught by the pair would not have been caught by an individual.
   
   Now, I'm playing devil's advocate a bit, but I'm also sharing the questions I would have if someone gave me this very convenient equation.

   Reply

8. Back to top

   Re: This assumes the developers actually work well together

   by totoro totoro

   Yes, I agree with you. good design and code reviews are more realistic solution to improve production quality. If pair programing greatly improves code quality then why not start quad programing.
   I think good design and code reviews by team members is more cost efficient.

   Reply

9. Back to top

   Re: This assumes the developers actually work well together

   by Theron James

   I have code for about 12 years and been a scrum master for 4 years. I coded solo for most of that time and am a really good programmer, a craftsman if I do say so. Once I got into Scrum, I tried pairing. I will never code alone again. NEVER. It's just like the book says, pairing is hard, but when done well, it is unmatched for creating high quality, elegant code. Like many things that are deeply worth doing, it's hard to put a specific ROI dollar on it. That does not change it's value.
   
   Pairing is not for everyone, and neither is high quality code. Most of the code written on this planet is crap in terms of quality and elegance. If you can let go of your ego, read a good book on XP and get XP training, you will be just like me, you will never code solo again.

   Reply

10. Back to top

    Code Reviews vs Pair Programming

    by Jerome St-Pierre

    I don't believe in code reviews for the same reason I don't believe in prohibition. I do believe in PP for the same reason I do believe in education.
    
    Instead of trying to catch every design flaws after the code is written, it seems to me that it makes more sense to code together and educate each others.
    
    From what I've seen from code reviews, the reviewers wanted to see as little changes as possible in the code to be faster to review. Then the reviewers have to catch up and review everything that was coded before each release. Then it is getting done on the fly at the end of each iteration because new high priority tasks are adding up in the backlog, just as usual.
    
    It is been quite a few times I read comments saying code reviews are more efficient than PP. I think a lot of people just want to be alone at their desk and follow their little routine. Writing some code, compiling, surfing the Web, reading their emails... I can understand them, it is obviously harder to communicate with someone that is pushing you to keep the focus.
    
    That said, I don't think PP is something that should be done all day long, depending of the complexity of the code that has to be written, I believe it should be scheduled for a few periods of maximum 90 minutes each a day (yes I watched Linda Rising presentation). It is definitely good for refactoring, complex bug fixing and core components design. I don't really see myself doing PP while working on a UI to add a few controls and wire events on some layer that is very lean and straight forward, on top of a design template already defined by the application architecture.
    
    Anyhow, I like team work and I always found a way to do PP indirectly when working in an open space, even in places that didn't encourage PP. Whenever I am not sure about how to design something or when I am stuck on a nasty bug, I will get a pair and 90% of the time I will understand the solution by myself because I am forced to explain the problem to my peer.
    
    Also, as it was said in some comments above, not every developer will get along very well, or sometimes it will take a little while to acclimate to a new pair. This is just natural.
    
    I also think it helps to enforce the bounds within the team and improve everyone skills much more faster than if everyone works alone in their own corner. I remember every time I worked with a new pair I learned or taught some cool shortcuts, tools or better ways of working.

    Reply

11. Back to top

    Re: This assumes the developers actually work well together

    by Dan Doyon

    I agree on the premise that the developers need to work well together. If there is unfamiliarity at the start (of PP), then familiarity will come rapidly. If there are ideological differences then friction may ensue. However, it could be a valuable experiment to try.
    
    In my prior position, PP became almost an obsession, to the point that there was no joy working alone. The main reason was that the amount of productive coding increased, we were always on same page and we both honed our technical prowess leaps and bounds over working alone. When we hit a technological snag, we'd start googling for answers (on our own laptops) and many times we'd encounter the same "special sauce" article that we would both agree on and we would be able to proceed.
    
    I would add one more thing, we also used test first development (and continuous integration) in the mix and used a one-step at a time approach that allowed us to evolve the code into elegant, concise and understandable. My new position, we're pretty waterfall-ish and I'm itching to get back to PP and my agile roots.

    Reply

12. Back to top

    Wrong assumption

    by Marco Silva

    You should not calculate the cost by the time a developer spent on a piece. The calculation should be over the total time spent to develop the sprinter (or the whole system). Because if the same piece needs to be process again that will affect more the cost of the project then the cost of pair programing on a piece.

    Reply

13. Back to top

    Team velocity

    by Wouter Lagerweij

    In my experience, it's not just about limiting the number of defects, or even time spent on one particular story/task. The way to measure the effects of pairing should be in the total team velocity.
    
    I think most people who've tried pairing have found that it is also a great way to keep focused and motivated, and as such is a major contribution to keep the team going forward. I'm convinced that the influence of that aspect is greater than that of quality improvements.

    Reply

14. Back to top

    Re: Team velocity

    by Dustin Whitney

    I'll second that

    Reply

15. Back to top

    solves suboptimization

    by Dustin Whitney

    Pair programming also solves the problem of suboptimization. Suboptimization is when you give a programmer a project and he/she focuses on the parts he/she knows best. For example if a developer is exceptional with dhtml/ajax they'll tend to focus on that aspect more than the back-end database code - they optimize a sub section of the code because they're better at working with it.
    
    
    
    When pair programming, it's likely that each member of the pair will have a different skill set and they will keep each other from suboptimizing pieces by acting as a check/balance against going to far down one path.

    Reply

16. Back to top

    Re: What about the cost of the pairing itself?

    by Dave Nicolette

    Hi Amr,
    
    I'm a bit surprised to see this coming from you, of all people! Pairing doesn't "cost extra" in terms of time. The pair produces as much code as the two programmers would produce working separately, but with fewer defects (as many as 86% fewer, per the Univ. of Utah study in 2000). So, the code produced by the pair requires less debugging time after the fact, and doesn't introduce as many defects into QA or production as would the "equivalent" code produced by individuals working separately.

    Reply

17. Back to top

    Re: This assumes the developers actually work well together

    by Dave Nicolette

    Hi Fred,
    
    Has that been your personal experience with pairing? I haven't found it so, myself. Nor do I agree that code reviews are more effective than pairing, combined with TDD and CI, at maximizing code quality. Are your comments based on direct experience in using the technique?

    Reply

18. Back to top

    Re: Based on many implicit assumptions.

    by Dave Nicolette

    Hi again Amr,
    
    You might find some of the studies referenced in George Dinwiddie's bibliography interesting. biblio.gdinwiddie.com/
    
    There is more than anecdotal reports from a handful of pro-agilists.
    
    Sorry to hear you're having trouble convincing skeptical clients. You've got my email if you need help with that. ;-)

    Reply

19. Back to top

    Re: solves suboptimization

    by Dave Nicolette

    Hi Dustin,
    
    Definitely agree, not to mention avoiding local optimization, and increasing bus number, and sharing knowledge, and... and... and...
    
    I remember reading an article that described a 1975 US Army study of so-called "two-person teams." It sounded very similar to what we call "pair programming" today. The two-person teams achieved 300% the productivity of solo coders on that project. This isn't "news." I think it's just that a lot of people are comfortable coding solo.

    Reply

20. Back to top

    Re: This assumes the developers actually work well together

    by Dave Nicolette

    It's amazing there are still people out there who think that way. Oh, the humanity!

    Reply

21. Back to top

    Re: This assumes the developers actually work well together

    by Mark Schumann

    You put a weak and a strong developer together, and you probably got mostly what the stronger developer would have written alone. But in the meantime the weaker developer got a running commentary on how the code works, offered some suggestions, learned why those suggestions wouldn't work, or maybe even improved the code somewhat. The stronger developer may have found a way to make the code better simply by answering the weaker one's questions. Silly little mistakes due to inattention are probably completely gone because of the "two pairs of eyes" effect, and so on.
    
    In the end you have 1.5 or 2.0 people understanding the code instead of just 1.0.

    Reply

22. Back to top

    Re: Code Reviews vs Pair Programming

    by Mark Schumann

    I agree. Pairing all day can be exhausting, and honestly, people just want their privacy even at work. Ninety minutes per day sounds about right in most cases though. I imagine (but haven't remotely tried to measure it) that the educational benefits of pairing get sharply diminishing returns after that point.

    Reply

• Older >