On Mon, Aug 29, 2011 at 11:46 AM, Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx> wrote:
Two people doing one job? Just to break even you have to
finish the job in half the clock time with the same number of
errors.
Well, in principle, it's supposed to be more than "one job" in the
sense that review is happening simultaneously. (I'm guessing most
shops don't even have such a thing as code review, but if they have
it, then it's certainly something not meant to be done by the original
programmer.)
Studies are mixed about the benefits of pair programming. It's rare
that two people can complete a single programming task in half the
time, but there can be "soft" benefits, which may be hard to put a
time or monetary value on. The one that is most persuasive to me (and
I'm not saying I'm a pair programming fan by any means) is that of
knowledge exchange. This includes both knowledge of programming
techniques or technologies, and knowledge of business rules and logic.
I could easily see a pair of programmers improve themselves more
quickly (and become more valuable to their company) working together
than individually, and this would bode well for future projects
(whether worked on individually or in pairs).
Another benefit cited by some studies that seems very plausible to me
is that pairs might be more disciplined and more likely to stick to
shop coding standards (less cutting of corners, less disregarding a
convention because one programmer disagrees with it, etc.). Even
without a reduction in bugs, an increase in conformity is probably
good for the code base and future maintainability.
I agree that ultimately, the best programmers probably are most
productive on their own or collaborating in more traditional ways
(talking to coworkers from time to time, but not spending hours
together at the same terminal or workstation). I think pair
programming could have value, even among the best programmers, but I
doubt it should be the primary way of working, certainly not for every
programmer on every project.
John
midrange.com
