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

[Curt Sampson <cjs@example.com>]

On Thu, 26 Jul 2007, Josh Glover wrote:

> Sure. But what does pair programming solve that a formal review
> process does not?

Well, for a start it reduces the bus factor. But more to this point, it
provides better coverage and shortens the feedback cycle drastically.

Certainly when doing team code reviews, I wouldn't want to review every
line of code. Having six or eight people looking at every line of code
that's written is expensive and provides little return. On the other
hand, having just one other person look at a line of code after it's
written is much cheaper, and provides at the very least a good sanity
check.

But a much more important point, and where the real savings come in, is
that code reviews are an after-the-fact process: if someone's gone off
on the wrong track, they've been off it for quite some time by the time
it hits the review stage. 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.

And frequently, anyway, the code doesn't get rewritten. In my
(admittedly limited) experience of code reviews, it's rare that you'll
sit down and rewrite the thing right then and there, unless the fix
happens to be a particularly good lesson for the entire group. More
often, it seems to me, you schedule a rewrite, and then who knows if it
will ever happen. If it does, it should probably be done by the original
author and the guy who knows the better way together, so that he can
learn from the event, at which point you're now pairing on the code
anyway, after having spent the time to have someone write it once alone.

To tell you the truth, I'm not sold on pairing everybody for everything
in a team of experts. I think there are some "stupid coding jobs" that
it's fine to have someone do alone. But an team of experts is going to
work pretty quickly to get rid of those sorts of things, via writing domain
specific languages or other techniques.

In groups with junior developers, however, as a manager I feel a lot
more comfortable in a heavily paired environment. When juniors pair
with juniors, they have to confront questions they might not ask of
themselves, get the chance to talk out what they're doing and get a bit
of extra checking. When juniors pair with seniors, they get to learn by
example how good programmers think, and get feedback on what they do.
When seniors pair with seniors, they kick butt on some of the hardest
problems. And when I'm in their pairing with everyone on a regular
basis, I have a much better sense of how well the developers are doing,
what they know, and where they should be concentrating on improving.

> Curt's contention seems to be that XP rolls spec, design, coding, and
> testing all into the pair programming context (is this a fair
> statement, Curt?)...

Yes, absolutely.

> ...so XP can solve all these problems at once.

I don't know that it "solves" the problems, but it certainly gets
everyone involved with the whole process and gives them the "bigger
view" of what you're trying to do. That can only help people make better
decisions.

After all, the best and most successful leaders not only know the right
decisions to make, but know how to bring the people under them to do the
same thing. Success is when someone working under an expert makes the
same decision that the expert would have made had the expert been doing
it himself.

> That sounds reasonable to me, but it seems that the cost in time is
> much higher.

When looked at in terms of overall cost vs. productivity, I'm fairly
certain it's not a lot higher. Whether it's somewhat higher, the same,
or less, is unfortunately extremely hard to quantify, because often the
real costs of a programming mistake aren't realized until days, weeks,
months or even years later.

> I also think that spec, design, and testing should be broken out from
> the coding process, as the required 考え方 is quite different...

I find these attributes to interact so heavily that I've not even
thought much about how similar or different the thought processes
are. This is very noticable in the area of automated testing (which
I rely on heavily). If you want to use automated tests, you need to
design things from the beginning to be testable in this way. Given two
designs that are otherwise more or less equivalant in comprehensibility,
functionality, cost, and so on, it one can easily be ten times more
expensive to test one than the other. That's why I think that TDD
(test-driven development, or even test-driven design--either way,
starting out with the question, "how am I going to test this?") is so
brilliantly effective: you start out optimizing the overall problem,
rather than just a piece of it.

(BTW, I'm not saying that you never produce stuff that's hard to test;
just that, when you do, it's a conscious decision, because overall
you've decided you'll save enough elsewhere to spend more resources on
testing, or have done something that lets you test less and still get
the level of confidence you need.)

> ...and I am not sure that people can context-switch effectively enough
> to represent that whilst pair programming.

Actually, context switching is much easier in pair programming because
a) only one person has to do it, and b) when he's done, he's got someone
there to bring him back into the other thing more quickly.

This is an area where I think Joel has missed something completely.
He advocates putting each developer in his own office and minimizing
interruptions and distractions, so that they don't fall out of the
"flow" when they get in to it.

Unfortunately, by hindering communications, this can also kill flow. If
I've got a question to which Joe can quickly and easily provide the best
answer, but he's not available, I send him an e-mail and then either go
on and do perhaps the wrong thing, or stop what I'm doing (killing my
flow) and go do something else whilst waiting. 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.

Pair programming lets this happen, because when an interruption comes
up, one developer can ignore it and continue on whilst the other deals
with the interruption. Then, when the other guy comes back, the guy who
continued can bring him back in to the flow quickly.

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