Pair programming sounds interesting, but I very much doubt I would be able to code at the same time I spend time talking. Maybe it is just too many years spend coding in solitude.
There is hard data[1] that points to pair programming being much more productive than programming alone. This seems a little counter intuitive but if you dig a little deeper it starts to make sense.
First, programming isn't menial work. You have to think. Thinking is the hard part, typing just a realization of our thoughts. Removing one pair of hands from a keyboard doesn't reduce capacity by half. For teams that gel, it can improve capacity!
It also produces far less bugs. Another set of eyes on the screen is helpful. If you consider the fact that costs rise exponentially with regards to the lifetime of a bug, it makes sense to catch as many bugs as early as possible.
It seems to make developers happier. If that's not a goal in and of itself (I think it is.. but that's me), developer happiness surely affects the long term health and buy in of your employees (or co-workers).
There are several other reasons that come into play that are mostly discussed in [1] but also around the net. Just take a quick glance and you'll see everything you need :)
Now, granted, not everyone works well together and for some people it seems that they just cannot get along with someone standing over their shoulder. There are some ways to simulate pair programming but still be on your own. You can start "rubber ducking" your code. You can decrease time between writing code and getting feedback on the correctness of that code. You can act as your own reviewer by reviewing the code you wrote yesterday.
But, in my opinion, there is no better tool in my toolbox to get through a hairy refactor or complex domain logic than another like-minded developer sitting next to me.
My limited experience of pair programming suggests that the biggest gain comes from having one brain devoted to the higher-level modelling and design task, and the other brain (with the hands attached) devoted to the lower-level intricacies of where to put the braces and semicolons, what headers to include to access which parts of the standard library, and so forth.
Because each brain can stay on one level without having to jump up and down the abstraction stack interruptions are lessened. Of course, if the higher-level brain starts to wander too far from the task at hand, the lower-level brain can interrupt, and if the lower-level brain gets tired of doing grunt-work, they can switch places.
I'd like to see some screencasts of these sessions on opensource projects where there's commentary about the actual code and the thought processes behind it as it's being written, especially a mature useful project like Samba, even though I'm not a C coder I think just seeing these guys work would be interesting.
I've tried (been made to try) working with another while coding. It was in each case frustrating, slow and a complete waste of time. I would want to fly down three objects deeper, amend an API, change the approach from list to bucket etc. And instead spent my time talking to this guy.
It didn't help that I knew the code, it was large and complex, and the design pattern was not one that was often used. So my partner was often catching up and never contributing.
Still, for systems programming, new development and especially debugging I do NOT recommend pair programming.
6 comments
[ 3.5 ms ] story [ 38.3 ms ] threadFirst, programming isn't menial work. You have to think. Thinking is the hard part, typing just a realization of our thoughts. Removing one pair of hands from a keyboard doesn't reduce capacity by half. For teams that gel, it can improve capacity!
It also produces far less bugs. Another set of eyes on the screen is helpful. If you consider the fact that costs rise exponentially with regards to the lifetime of a bug, it makes sense to catch as many bugs as early as possible.
It seems to make developers happier. If that's not a goal in and of itself (I think it is.. but that's me), developer happiness surely affects the long term health and buy in of your employees (or co-workers).
There are several other reasons that come into play that are mostly discussed in [1] but also around the net. Just take a quick glance and you'll see everything you need :)
Now, granted, not everyone works well together and for some people it seems that they just cannot get along with someone standing over their shoulder. There are some ways to simulate pair programming but still be on your own. You can start "rubber ducking" your code. You can decrease time between writing code and getting feedback on the correctness of that code. You can act as your own reviewer by reviewing the code you wrote yesterday.
But, in my opinion, there is no better tool in my toolbox to get through a hairy refactor or complex domain logic than another like-minded developer sitting next to me.
[1] http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.P...
Because each brain can stay on one level without having to jump up and down the abstraction stack interruptions are lessened. Of course, if the higher-level brain starts to wander too far from the task at hand, the lower-level brain can interrupt, and if the lower-level brain gets tired of doing grunt-work, they can switch places.
It didn't help that I knew the code, it was large and complex, and the design pattern was not one that was often used. So my partner was often catching up and never contributing.
Still, for systems programming, new development and especially debugging I do NOT recommend pair programming.