begin quoting Andrew Lentvorski as of Tue, Mar 18, 2008 at 02:18:12PM -0700: > James G. Sack (jim) wrote: > > >Still, I think the argument is that _when it works_ and/or _if done > >right_ (and _if it suits you_), the productivity increase is very large, > >indeed. The detection of stupid errors alone may pay the bill. And the > >consequential benefits mentioned by Andy are really there. > > No one has ever documented a productivity increase from this. Ever.
What sort of documentation are you looking for? The handful of times I've honestly given pair-programming a go, the productivity boosts were *tremendous*. It's also draining. The longest run of pair-programming that I've managed was a little over three weeks. The shortest productive run was 4 hours (after about a month of offline design niggling in respective notebooks). I've also worked with programmers where it wasn't really pair- programming, but rather coaching; the second person was a drag, and the net output was less than I could have done alone. If the second programmer can't or won't contribute, or contributes nonsense, there's no way it can "work". It was just as draining as pair-programming, but a lot less fun. So, like most things, YMMV. > It's one of my biggest gripes about the Extreme Programming(tm) folks. > Nothing even close to resembling concrete data. Do any of the methodologies have concrete data? When Beck's XP book first came out, I talked to a guy who managed to convince his company to try it out on a small scale. They gave him some junior programmers, and his XP team out-performed the senior engineers (more working, tested, debugged code checked in per week, deliveries made on schedule or earlier, etc.) -- and after six months, they shut down his experiment. Granted, this is hearsay -- twice removed by the time you get it. Who knows what the actual results were... his claim was that they were so successful that the threatened middle management, and that's why they were shut down. *His* data will never be published. On the flip side, I worked with some code that was produced "according to XP principles", and it was every bad thing you could say about it. Lan's characterization of XP (which I believe is way off the mark) would indeed apply -- sloppy, undocumented, fragile, broken code. I assert that although the programmers had *claimed* to have been following the XP guidelines, they were, in fact, blowing smoke. XP produces lots of artifacts: a bunch of story cards, a ton of task cards, and a metric boatload of unit tests... none were to be found. I assert that XP requires a better-than-usual manager (aka coach) and (at least initially) more discipline than "normal" development. Those who claim that they don't need a manager or discipline while practicing XP are lying, or at least deceiving themselves. Of course, once you have a better-than-usual manager, it's likely that any non-pathological methodology will work, which brings us back to the idea that the methodology is irrelevent. Get good people, and you'll get a decent product. . . -- We've seen some spectacular failures of the up-front design approach. Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
