A Dollar Value On Pair Programming
- Share
-
- |
Read later
My Reading List
"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?
What about the cost of the pairing itself?
by
Amr Elssamadisy
And that all depends greatly on the example given being generalizable....
Re: What about the cost of the pairing itself?
by
Mike Bria
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
This assumes the developers actually work well together
by
Fred Smith
Re: This assumes the developers actually work well together
by
Mike Bria
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
Re: What about the cost of the pairing itself?
by
Mark Levison
· 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.
Re: What about the cost of the pairing itself?
by
Mike Bria
Based on many implicit assumptions.
by
Amr Elssamadisy
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.
Re: This assumes the developers actually work well together
by
totoro totoro
I think good design and code reviews by team members is more cost efficient.
Re: This assumes the developers actually work well together
by
Theron James
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.
Code Reviews vs Pair Programming
by
Jerome St-Pierre
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.
Re: This assumes the developers actually work well together
by
Dan Doyon
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.
Wrong assumption
by
Marco Silva
Team velocity
by
Wouter Lagerweij
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.
solves suboptimization
by
Dustin Whitney
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.
Re: What about the cost of the pairing itself?
by
Dave Nicolette
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.
Re: This assumes the developers actually work well together
by
Dave Nicolette
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?
Re: Based on many implicit assumptions.
by
Dave Nicolette
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. ;-)
Re: solves suboptimization
by
Dave Nicolette
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.
Re: This assumes the developers actually work well together
by
Dave Nicolette
Re: This assumes the developers actually work well together
by
Mark Schumann
In the end you have 1.5 or 2.0 people understanding the code instead of just 1.0.
Re: Code Reviews vs Pair Programming
by
Mark Schumann
Educational Content
Large-Scale Continuous Testing in the Cloud
John Penix May 24, 2013
.jpg)
Managing Build Jobs for Continuous Delivery
Martin Peston May 24, 2013
Clojure in the Field
Stuart Halloway May 23, 2013
Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think