This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I seem to recall from reading about pair programming that a team would experience an overall drop of velocity of 15% - and see an increase in quality by a factor of five, plus better new-guy-ramp, elimination of "hit-by-a-bus factor", etc.
But for the moment, I would like to focus on the change in velocity. I would like to simply make a list of all the things that will increase the velocity. With this list, people that are skeptical of these numbers can build their own numbers. Convince themselves of what their team velocity might be.
So right off the bat, team velocity is decreased by a factor of 50% - this is the first thing that pops into the heads of folks when they first hear of pair programming. But then there are velocity gains due to pair programming that are not as obvious at first blush.
So, let's say that "X" is 5 programmers working solo at five workstations. Now we add five engineers to the team, and no more workstations. We are doing pair programming "as much as is reasonably possible".
So I think we can all chip in as much as we want for categories and numbers. In the end we will have a list of categories and non-believers can put their own numbers in and come to their own conclusions.
I think the first category is "part time solo". Doing pair programming 100% of the time is silly (IMO). While a pair is working on a task, if one of the pair needs a bio break, often the other person keeps working. If one leaves work early, the other keeps going. If one shows up to work early, they start until the other shows up. Their lunch scehdules might not be perfectly aligned. So I think if you figure in an average of solo task work in the morning of a half hour, and solo work in the evening of an hour, plus maybe an extra half hour picked up through the day, this totals up to 2 hours. Let's say that half of that would have been worked anyway, but with the pair, we gained an hour. So X is 8 hours. Is it fair to say 10%?
How about typo correction? A pair just spots typos and mentions them. Could this gain us 1%?
How about e-mail, web surfing, non development tasks (both professional and personal) that are effectively eliminated due to pairing. You can't read your e-mail while pairing! Can we say that that gets us 10%?
So here's the start of this list:
"part time solo" 10% "typo correction" 1% "reduction of non-dev stuff" 10%
So I'm up to 21% using my own numbers.
I'm thinking there are probably a dozen more categories and we can all pitch in our own numbers!
depending on all the projects different people work on, one person may go to a meeting and the other keeps working. i don't think it gains us much, but possibly another 1%.
and how about all the stuff you have to do that's not directly programming, but still required? when i finish a log, i have to 1) create a log for the doc people to look at 2) update the bug tracking log 3) do a code review with another dev 4) check in the code to all the branches 5) send emails to the right poeple saying it's done/ready for testing
now, my company might not be the most efficient when it comes to requiring all this stuff, but i think some of it carries over to all companies. your code reviews are simpler/faster. one person can update the error tracking log while the other is checking it in, etc.
although as i think about this, it might be a wash. what takes one person 30 minutes would take two people 15 minutes...
There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
Well, meetings might be fewer and/or faster, as well as emails and IMs. that is, included in the pair programming is communication costs otherwise paid elsewhere. How much you save really depends on the type of project.
There's also code reviews. Pair programming incorporates a code review into it. While I wouldn't necessarily eliminate code reviews, presumably this makes them faster because it's already been reviewed once. This applies both to finding bugs as well as to enforcing coding standards.
The continuation of flow might improve. That is, when one programmer goes to the bathroom, or to get coffe, etc the fact that the other programmer continues might improve reimersion into the flow, reducing the typical estimated 15 minutes to a smaller number.
Shower reduction. Now that you're sitting next to someone else, you can simply choose not to shower and blame the smell on the other guy. (OK, so maybe that's taking it too far. :-p)
Vacations. If you have code ownership and no pairing, then when one guy goes on vacation, development on "his" code comes to a screeching halt. This can hold up a whole team. Say a guy gets 3 weeks; then that's 6% of the time that "his" code is locked down. With knowledge transfer due to pairing other people will be qualified to do the work.
You haven't even mentioned debugging. This is hard to quantify, easy to measure, but it's a double-digit improvements, for sure. Without pairing, you code, test, scratch your head, fix, test, scratch your head... with pairing, there's a much better chance you'll get it right the first time. Less debugging, more coding.
There's the tool-education factor. If one guy learns a really cool shortcut that saves him work, then with pairing, everyone will soon learn about it. "How did you just do that?" is something I hear (and say) all the time during pairing. This is easily a 5% thing, or more if you have a lot of junior programmers.
Also design aspects should be improved. If one developer has to think of the design there is a bigger chance of not designing it the best. Again two minds working to gether can find things that other might oversee, so the design could be created quicker, in theory. Thus a better design will also factor into the speed of the development. I like the two pair of eyes theory. Also, you mentioned the "Hit by bus" syndrome. A very big one in my mind.
Originally posted by David Rocks: will a bad programmer paired with a bad programmer make them as good as a good programmer?
One very important aspect of pair programming that many critics overlook is that you have to rotate pairs, ideally more than once a day. You can't stick the two most junior partners together off in a corner for a week. But if Junior A pairs with Senior A in the morning, then with Junior B in the afternoon, then Junior B gets the benefit of what Senior A managed to teach Junior A, as well. Knowledge diffuses through the whole team.
But frankly, I disagree with your assertions here. Two "bad" programmers (I don't like this term; people aren't "bad", they're just less experienced) can, in fact, help each other. They won't be interchangeable. Each will know something the other doesn't. Two "good" programmers will also have things to teach each other.
One group that doesn't fit into pairing are the "cowboy" programmers, those who don't like rules, and like to go off and do things their own way. Historically, there's a lot of machismo associated with this archetype: the swaggering hero, such a genius that he can come in over the weekend and rewrite the whole application in Managed Perl. The reality is that these "geniuses" almost always are more trouble than they're worth. Their output works but is incomprehensible and unmaintainable. Their egos are so huge that they are not interested in learning to improve themselves, and as a result their professional development is arrested at the garage stage. Good riddance, I say.
- more discipline: "shouldn't we write a test for this?"
- catching stupid errors - such as off-by-one errors
- having to explain what you are doing to your partner, thereby clarifying your own thoughts
- catching misunderstandings: "I understood our customer to mean something different - perhaps we should ask again."
- easier to get back into the flow when you got interrupted
- getting inspired from the conversation with your partner
Some of these things are realy hard to put numbers on - a creative idea really can safe you several orders of magnitude of effort. But you can't rely on it, of course.
And some of them are hard to put realistic numbers on until you actually experienced it. And once you did, you probably don't need the numbers any more to be convinced...
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
This is based on classroom observation alone, but when teaching to programming groups that come from the same company, I've noticed this. Students look at each other's code all the time, as a matter of habit. What's most interesting to me is how they note each other when something's amiss: "you're treating that compression like a discount," "if you're going to add to the library, are you going to document a compelling need for another widget that does that?" and "it looks like you're reinventing dynamic binding."
All these statements remain in my ear because even without seeing the observed code, I had an idea what was happening. Furthermore, it opened my eyes to methods I have used or taught and how they fell short under these same observations. It's hard to put a number to it. I remember each one of these three statements -- where I heard, when I heard, who said it. Each one fundamentally altered my understanding of how I wrote code and how I taught it. I daresay if I postured myself The Authority while teaching I would never have learned a tenth of what I did.
Good pair programming is supposed to teach. It's not a benefit, it's a primary intent. It's not a question of skill level, but motivation.
<TANGENT> I suspect when people talk about bad programmers/programming they're thinking of soul-less or brain-dead work which, again, is not bound to lack of skill so much as lack of effort. Anyone who's been required to do a group project in school had at least that chance to learn the difference. If you missed it, do another group project. There's something to learn even in the mere dynamics of that arrangement.
Having said that, I hated every group project I was ever pushed into. Why? Because they were formed as committees, not collaborations, and assumed ipso facto to be self-reliant, self-sustaining. Translation: most professors seemed to think this was a way to no-cost way of "facilitating" student work, as in "avoid teaching." The energy of these groups always sunk to the level of the leat-motivated. The tension of the group rose with the person most put-off by the least-motivated.
That's what you have to fear in pair programming -- people who don't really want to do the work. Pair programming spots, fairly or unfairly, people who can't do the work far faster than separating everyone ever would. But someone has to watch, manage, analyze results -- it doesn't just happen on its own. </TANGENT> [ March 20, 2006: Message edited by: Michael Ernest ]
Make visible what, without you, might perhaps never have been seen. - Robert Bresson
While one person is at the keyboard, another is thinking things through. This has been said before, but think about the math of that for a moment:
I can average around 50 - 60 words per minute when transcribing. But when developing code on my own, or writing documents on my own, that speed is greatly reduced as my brain is doing multiple things at once.
I have quite often seen programmers work on a section of code, then stop and think about the next step (yes, even when it has been scoped and designed before hand).
With two programmers, one can be thinking about the next step while the other is coding. Then 10 minutes later they swap around.
Think about all the times you have done a bit of code, then stopped and thought about what you have done; whether you have covered everything; what tests you are going to run; etc. Much of that slack period will be covered by the other person taking over. In my opinion this would be a 10% (at least) gain.
This style of working can work especially well where you have one person writing a unit test. While the test case is being developed, the other coder is thinking about how to code to pass the test. When the test case is complete, the two programmers swap over. There was no time lost while thinking about how to develop the solution. While the second coder is coding the method, the first programmer is keeping an eye on the code to see if the second programmer made an assumption that will either cause the test to fail or that might indicate a hole in the test case; while simultaneously thinking about how to develop the next test case. (After several test cases / methods have been developed you would swap the programmers roles over).
Here is an older CrossTalk Article about pair programming. The team achieved a 127% increase in SLOC over the average (whatever that's worth) with 0.001 as many defects. See if any of his thoughts about why it worked are useful.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by Stan James: Here is an older CrossTalk Article about pair programming. The team achieved a 127% increase in SLOC over the average (whatever that's worth) with 0.001 as many defects. See if any of his thoughts about why it worked are useful.
That has to be one of the best articles I've read in a loooooong time. And I haven't finished reading it yet.
Joined: Jan 29, 2003
And didn't the experiment take place in 1975? Well before we had a name for pairing. Pretty amazing.