use Perl

• '2-per-computer' ne 'pair-programming' (Score:1)

  by Adrian (66) <adrianh@quietstars.com> on 2004.07.12 16:57 (#32419) Homepage Journal

  One theory of pair programming is that it keeps developers honest. That doesn't seem to be as true as I thought. I've watched a programmer get his tests passing, claim he was finished and then had his pair sit silently, despite the fact that the follow-up refactor was not done, the code needed some serious cleanup and the tests were woefully inadequate.

  For me this, and the other examples you list, aren't demonstrations of pair programming not providing benefit, but examples of people who are not doing pair programming.

  You actually have to do pair programming before you can figure out whether it benefits you, and just because two people are sitting in front of a computer doesn't mean that they're doing pair programming.

  If you have two people on stage and one of them is playing a gameboy and the other is asleep then they ain't singing a duet :-)

  This may seem like nitpicking (okay - it is nitpicking ;-) but I think it's a distinction that you have to be careful about. One of the problems I've come across when introducing people to agile practises are people saying "Foo doesn't work - we tried it" when they actually mean "We tried to do Foo and couldn't make it work".

  There's a difference between:

  • Cycling doesn't work.
  • I cannot ride a bike
  • I tried to ride a bike once and fell off

  Somebody falling off a bike isn't an sign that cycling offers no benefits.

  Not that I disagree that some people seem incapable of pairing programming because their personalities don't bend that way. In new teams I try my very best not to hire them. In old teams add a lot more code reviews or encourage them to do stuff that doesn't need pairing.

  Reply to This