Re: Pair programming [ was: Re: [tlug] [OT] Good IT Resume

[Curt Sampson <cjs@example.com>]

On Sat, 28 Jul 2007, Josh Glover wrote:

> > If you can catch someone taking a sub-optimal
> > approach when they start to veer off the rails rather than after they've
> > spent hours coding something the wrong way, you can save yourself the
> > trouble of rewriting the code.
>
> But I thought late changes were cheap in your projects?

They are as cheap as early changes. But it's better not to have to do
the rewrite at all.

> You win on turn-around time with pair programming (can we abbreviate
> it as PP? what does the XP literature use?)...

"Pairing," often.

> ...but I win with many eyes
> making all bad designs obvious, to mis-quote Linus. ;)

Actually, most all eyes eventually fall on most all bits of the code
in XP, too, since everybody works (or should work) on pretty much
everything at some point.

> Not at Amazon. Code is not allowed to be deployed to production
> without the sign off of at least one reviewer.

So you're saying that when you identify a design or some code that's not
as good as it could be, you always rewrite it, even if it works? Even if
you could instead spend the time writing another piece of code that will
make you money in the short term?

> But what happens more often in my work is that I coordinate with an
> engineer on the other side of the Pacific, meaning that we have a
> hour-long window once a day for communication....

Ouch. That puts you at such a tremendous disadvantage already that I'm
not surprised you're not too worried about pairing versus code reviews.

> I actually find this better than PP for most problems, as it allows us
> to coordinate the design which each focusing on specific areas of the
> coding.

Coding is design, at least for me. I often change the design as I code
something and realize better ways to do things.

> Well, I value my flow, and this is why I don't consider PP a very good
> use of my time. I am much less efficient when I am not in the zone,
> and I find it harder to get two people in the zone at the same time.

Both people in the zone is certainly the best. But having one in the zone
is still far better than none, and having one in the zone means that you
can bring the other half of the pair back into much more quickly. Let me
try to restate my argument again.

There are two ways to attack the problem of interruptions making people
lose the flow. One is to try and minimize the interruptions, which
can work well, but has a pretty bad effect on communication. And that
in turn can make people lose the flow as well, since when they need
information or feedback, if they can't get it quickly, they may have to
stop what they're doing and thus fall out of the flow.

The other way of attacking the problem is to find a way to get people
back into the flow much faster. That's what pairing can do.

So:

> > Whereas if I can grab Joe right that instant, get the one-minute
> > analysis I need from him, and go on, I stay in flow.
>
> But what have you done to Joe's flow?

I may have broken Joe's flow, but he can get back into it quite quickly
by sitting down with his pairing partner, who is still in it.

> Are you so arrogant that you think his time is worth less than yours?

No. I'm merely trying to optimize the entire team, as opposed to one
person.

cjs
--
Curt Sampson       <cjs@example.com>        +81 90 7737 2974
Mobile sites and software consulting: http://www.starling-software.com