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

["Josh Glover" <jmglov@example.com>]

On 26/07/07, Curt Sampson <cjs@example.com> wrote:

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

Code reviews on my team involve one primary engineer, and the team is
CC'd so that they can glance at the change and keep on top of what is
going on with the code.

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

But I thought late changes were cheap in your projects?

We solve this problem with a design review early in the process, with
a re-review sent to the whole team and brought up in the daily standup
(we are not exactly a Scrum team, but we do use some of the ideas from
Scrum, just as we use some from XP) whenever sufficiently new design
is introduced.

You win on turn-around time with pair programming (can we abbreviate
it as PP? what does the XP literature use?), but I win with many eyes
making all bad designs obvious, to mis-quote Linus. ;)

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

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

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

Sure, and I have done PP or close enough on various hard problems, and
realise the benefit of two good brains bouncing ideas back and forth
at the speed of thought. 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,
so most stuff happens on email. 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.

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

Sounds reasonable, and we do something very much like that at Amazon,
though it is not PP, it is more bidi "mentoring". :)

> When juniors pair with seniors, they get to learn by
> example how good programmers think, and get feedback on what they do.

Agreed. But again, I think mentoring is a better use of my time than
full-fledged PP.

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

Makes perfect sense in your environment; it would be difficult in mine.


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

+1

We use TDD on my team.

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

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.

Joel's analysis, BTW, is the same as Paul Graham's:

http://www.paulgraham.com/gh.html

I agree with them both: the best programmers I have met need doors
that close and co-workers than know when to leave them the hell alone.

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

But what have you done to Joe's flow? Are you so arrogant that you
think his time is worth less than yours?

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

This sounds reasonable, but I'd have to see it in practise.

-- 
Cheers,
Josh