A Dollar Value On Pair Programming

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....

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

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.

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

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.

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?

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.

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.

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.

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.

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.

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.

I'll second that

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.

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.

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?

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. ;-)

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.

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

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.

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.