Extreme Programming - Pair programming (was: The Irony of Extreme Programming)

Author

Pair programming (was: The Irony of Extreme Programming)

Dirk Thierbach

2004-06-03, 7:08 pm

Randy A. Ynchausti <randy_ynchausti@msn.com> wrote:
> The point is ***NOT*** how fast the keys can be pushed. The point
> is that only one person can be pushing the keys at one time.

Yes, but normally programming doesn't consist only of "writing down
code" (unless the code is trivial). Programming also means you have to
make design decisions. When pairing, one mode of operation is that
the developer at the keyboard does the actual programming, while the
other "thinks ahead" and does the designing.

> Therefore, the limit to how much code is entered in the system is
> how fast that one person's brain works in developing the code.

Not necessarily: You have two brains working in parallel. If the code
is trivial, and there's no need to do any thinking, e.g. if you
have to hack in tables or raw data or whatever, you can do this without
pairing.

And there are other effects: With four eyes, it's easier to catch
stupid errors and typos, which otherwise would require a
compile-and-fix cycle to detect. Also, when pairing, it's a lot easier
to focus, and you won't as likely get detracted by side issues, or
really stupid ideas.

If you combine this with the "parallel brains at work" obvservation
(one for programming, one for designing) you will get about the same
amount of (bug-free) code with a pair as you'll get from two single
developers.

Of course, this doesn't work always; especially it doesn't work
when pairing for a longer time (because that's too exhausting).

["Matrix" theory with a fast and a slow approach]

I don't get this argument at all. See below.

> There is a 50% chance (1 out of 2) Developer A selects the slow approach and
> development takes longer. But there is a 50% chance that Developer A
> selects the fast approach and development is shorter. Are you still with
> me?

So far, that's easy.

> Now let's pair Developer A up with Developer B and hopefully they get things
> done faster. But now, in addition to taking the time to select an approach,
> Developer A and Developer B have to spend time deciding which approach the
> pair is going to take. That slows things down a little.

Ok, but this effect is IMHO more or less neglegible.

> Let's hope that they select the fast approach more often to
> compensate. Here are the pair's choices:

[fixing table for fixed-width font]
> Developer A Developer B Pair
> ========= ========= ====
> Fast Fast Fast
> Fast Slow Fast
> Slow Fast Fast
> Fast Slow Slow
> Slow Fast Slow
> Slow Slow Slow

Is this just an example of what could happen? If yes, you cannot draw
any conclusions from it. If no, I don't see how you decided on the
choices of the pair.

Normally, I would expect the developers to pick the fast approach in
most cases: If developer A comes up with a fast approach, and
developer B wants a slow one, developer A can quickly explain "yes,
but my idea is better, because ..." and developer B will soon say "oh,
I see. Let's take yours". So there should be a 70% chance (i.e.,
slightly less than 75%) that they choose the fast approach.

> Oops, there is a 50% chance (3 out of 6) that the pair will select
> the slow approach and development takes longer.

And here I get totally

. If for the pair (in your example) the
probabilities are the same as for individual developers (namely, 50%),
then both should perform in the same way -- if you assume in that you
(usually) get the same amount of (bug-free) code in the same time, no
matter if you have a pair or two individuals.

And even if you don't assume that, any difference between the
performance cannot come from the way they make their choices, if
in both cases the probabilities are 50%.

> This results in the pair spending twice the man-power to get the
> same results as the individual.

I don't see how this follows from the above reasoning. I don't argue
with your experience; none of us were there, and we really have no way
to find out what went wrong in this case. Maybe those particular two
developers just don't happen to pair well together, maybe they made
some mistakes. I don't know, and arguing about it will probably lead
to nothing. And it's completely justifiable that with this experience,
you shouldn't encourage pairing again (unless you have some
maneuvering room for experiments), and especially not in a similar
way.

But I think (excuse me directness) that the above theory to explain
your single data point doesn't work at all.

- Dirk

Randy A. Ynchausti

2004-06-03, 7:08 pm

Dirk

[color=darkred]
> Yes, but normally programming doesn't consist only of "writing down
> code" (unless the code is trivial). Programming also means you have to
> make design decisions. When pairing, one mode of operation is that
> the developer at the keyboard does the actual programming, while the
> other "thinks ahead" and does the designing.

At some point, the code still has to get from the mind to the computer
through the keyboard! The thought process that leads up to the typing can
be considered as time typing when no keys are pushed. Therefore, the
developer does not come close to the rates that were noted previously (by
some other poster).

Regards,

Randy

Sponsored Links