Defending the Python lanuage...

[Jason Voegele]

Cliff Wells <logiplexsoftware at earthlink.net> wrote in message news:<mailman.1013120294.28856.python-list at python.org>...
> On Thu, 07 Feb 2002 16:14:50 -0500
> Michael Chermside wrote:
> > Peter Milliken writes that he didn't know we had such a surplus of 
> > programmers -- this is a common misconception. Suppose that, working on 
> > your own, you get X amount of coding done in a day. If we could spare a 
> > second programmer to stand there and just help you out -- someone to 
> > bounce ideas off of, to watch for typos, to suggest things that you had 
> > forgotten -- then you'd get MORE done... say X * k.
> 
> I can get this by having someone in close proximity who I can interrupt on
> occasion.  He doesn't have to watch the _whole_ time, just when there is
> something interesting or puzzling or when there are design issues to be
> discussed.  I do the same for him and since we're able to both code
> independently _and_ collaborate, I suspect k is even higher than in
> pair-programming.  Not unlike open-source development, but in this case the
> developers have a faster, better means of communication (face-to-face
> versus the net).

(First, take everything I say with a big grain of salt, because I've
never done pair programming, only read about it.)

I doubt that k in the above scenario would be as high as it is with
pair programming.  The idea is that one person is "driving", typing in
the code, and the other is observing.  The person driving is usually
concerned with the low-level details of whatever it is she's working
on, such as the syntax for the for loop in the language, while the
observer is freed to think about higher-level issues such as design,
and how the code can most clearly express its intent.  There is a lot
of communication and feedback between the two individuals in the pair
that leads to code that is simple, relatively bug-free, and expresses
its intention.
 
> > If k is 1.05, then you are getting a 5% speedup by having someone around 
> > to help out. If k were 3, then you'd get THREE TIMES as much done. If 
> > THIS were the case, then it'd be worth it to your company to tell 
> > someone else to stop working on their own and just help you out! The 
> > break-even point is somewhere around k=2.
> > The exact value of k depends on LOTS of things, including the 
> > personalities of the programmers involved, the kind of work involved, 
> > etc, but I have heard several different annecdotal estimates that place 
> > k at just-less-than 2. (Maybe k=1.9 +/- 0.2 for typical situations.)
> 
> If if.  No doubt things such as personality are going to be a huge factor. 
> I guess that sums up my assertion: the type of personality attracted to
> programming is not the type to endure watching someone else code.  My
> fingers would twitch themselves numb.

With pair programming, the roles switch back and forth frequently and
rapidly.  No one person is driving for more than a half-hour, and
typically you'll switch drivers much more often than that (say 10
minutes or so).  Anytime you, as an observer, want to communicate
something about the code that you can't express in a simple sentence
two, you take the keyboard and express it directly.

> To have pair-programming work you
> would need two programmers who: 
> 
> 1.  have similar skill levels

This one is not true.  Part of the point of pair programming is the
feedback and mentoring process that's involved.  A junior programmer
can learn a lot from a senior programmer.  Even the senior programmer
will occasionally learn something from the junior programmer.  And at
least in XP, pairs are not fixed.  You pair with many different people
during a day, some of whom will at a lower skill level, and probably
some of whom will be at a higher skill level.

> 2.  like and respect each other

This certainly helps ;-)

> 3.  have compatible programming philosophies

I'm not sure about that one.  Maybe.  XP alleviates this with some of
its other practices (TestFirst,
DoTheSimplestThingThatCouldPossiblyWork, RefactorMercilessly,
CodingStandard).



> Did I mention you need two programmers?  My current employer has only one -
> yours truly.

That does indeed make it difficult ;-)

> 
> Besides, if I understand correctly, k = 1 = normal productivity for a
> single programmer.  Then your own "anecdotal" estimates place
> pair-programming just below individual programming (for 2 individual
> programmers, k = 2, for 2 pair-programmers, k = 1.9), so what's the point?

Well, assuming k < 2, the point is code that is clearer, more
maintainable, well-designed, and relatively bug-free.  It's like doing
code inspections...constantly, all the time.  Except it works better. 
In addition, two people now readily understand the code instead of
just one.  Combine this with XP's CollectiveCodeOwnership, and
frequent pair swapping, everybody understands a lot more about the
system than they would otherwise.  Perhaps these factors could result
in a k > 2?

> > If k is close to 2, then there it might NOT be a stupid idea to put 
> > programmers in pairs, even without a surplus. Particularly because we 
> > expect some additional benefits in addition to the coding speed, like 
> > fewer bugs and better sharing of the knowledge among the coding team.
> 
> No doubt, assuming k is close to 2.  That would seem difficult to measure
> with any degree of accuracy and so seems like a big assumption.

There's been at least one study (can't recall who or where, sorry)
that showed k to be fairly close to 2.  I recall some discussion of
other studies currently being undertaken.

> > As for Cliff Wells' contention that he doesn't know many programmers who 
> > would want to do this, I have to differ. There are clearly some 
> > programmers who absolutely hate working in pairs, but there are also 
> > many others who LOVE it.
> I wonder: would you be the person doing the typing or the person doing the
> watching?  For the person doing the actual coding, I can see where this
> wouldn't be so bad (it'd probably be great), but I find it difficult to
> believe that watching someone else code would be something any programmer
> could love for very long.

You do both! Pair programming encourages frequent role change as well
as the frequent pair swaps.
 
> Interestingly, your last paragraph brings to mind previous posts on this
> thread where code reviews were discussed and I asserted that I didn't
> consider them useful, not because they wouldn't be effective, but because
> programmers won't do them.  In this case, it's the managers who won't do
> it.  Even if pair-programming is very effective and programmers love it, I
> doubt that managers and employers are ever going to be very receptive to
> the idea, which IMHO makes it somewhat less than useful.

Well, some managers will be receptive, and perhaps those that aren't
receptive right now can learn from their successes (or failures).

Jason Voegele