Defending the Python lanuage...

[Cliff Wells]

On Thu, 07 Feb 2002 16:14:50 -0500
Michael Chermside wrote:

> >> Really? What an unusual idea - I didn't realise we had such a surplus
of
> >> programmers to advocate something like this :-)
> > 
> > This is a little more "extreme" than I was referring to as well.  The
idea
> > of two programmers sitting at the same computer doesn't really go over
well
> > with me... I was referring having two programmers sit side-by-side at
> > separate computers, working on different parts of the same program
versus
> > having one programmer work in isolation.  Indeed, I don't know many
> > programmers with the patience to sit and watch someone else type ;) 
> 
> 
> Ermmm.... No.
> 
> When XP or Agile Programming advocates talk about "pair programming" 
> they really DO mean one keyboard, two programmers.

Yes, I was aware of this from the previous post.  I was simply disagreeing 
;)

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

> 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.  To have pair-programming work you
would need two programmers who: 

1.  have similar skill levels
2.  like and respect each other
3.  have compatible programming philosophies

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

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?

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

That may very well be the case.  I obviously have never tried it (and
probably won't, since the idea would never fly with anyone I've ever worked
for), plus I've haven't worked at dozens of companies with hundreds of
programmers to give me the empirical data I would need to make any definite
statements about it.

> Now I just wish I could convince my company to consider doing pair 
> programming. Because for *ME* personally, k is around 3 or 4.

Working by myself, k for me is already around 3 or 4 because that's how
much work I do around here: enough for 3 or 4 people... I'm trying to
reduce k, dammit ;)

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.

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.

Regards,

-- 
Cliff Wells, Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 x308  (800) 735-0555 x308

"Then with your new power you'll accomplish all sorts of cool stuff 
 in no time, and We'll All Be Sorry.  At that point you can either 
 gloat a bit, and then relent, or go ahead and send the robot army 
 after us." - Quinn Dunkan