Re: XP and Pair Programming

Thank you for acknowledging the counter-arguments, it's a very
refreshing attitude.

Nick Malik [Microsoft] wrote:
> "Isaac Gouy" <igouy@xxxxxxxxx> wrote in message
> news:1124982690.748299.108460@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> >> > In other studies of pair programming is any increased productivity
> >> > simply explained by increased work-effort?
> >> >
> >>
> >> You have unfairly excerpted a specific sentence. The author, through
> >> analysis, details out the reasons why he believes that pairs were more
> >> productive in this case. Taking a single sentence out of context is not
> >> a
> >> good measure of an open mind.
> >
> > Humbly suggest that your original post selectively excerpted specific
> > sentences ;-)
> >
>
> In my defense, I excerpted the paper's conclusions. That said, you are
> correct in stating that any excerpt runs the risk of being interpreted out
> of context. I humbly defer.
>
> >
> >> The reasons that the author details include Brainstorming, continuous
> >> design
> >> walkthrough, focused energy, mentor, motivation, and problem isolation.
> >> The
> >> negatives included counter-productivity due to bad pairings ("two prima
> >> donnas") and the need for better colocation of the team in a war-room
> >> environment (which was lacking in this study).
> >>
> >> In my personal experience with pair programming, I admit that I spent
> >> less
> >> time on breaks, but that was not because I was being worked harder... it
> >> was
> >> because I was enjoying my work more. I cannot say but I can guess that
> >> some
> >> of the same feelings were being felt by the teams in the quoted study.
> >
> > Shouldn't we use the simplest explanations first?
>
> Certainly, if someone enjoys his work more, he will spend more time on it.
> We certainly have to consider that "time spent at the monitor" is a valid
> input to the productivity formula. What I am pointing out is that the best
> way to increase this time is by making it enjoyable, not by force or
> intimidation. Have you worked in a pair?

Infrequently.

> The other variable to add to this equation is productive output (lines per
> hour of keyboard time). It would be a good experiment to see if you can
> increase the output of quality code by intimidating people to sit at their
> keyboards longer. I would be surprised if this were the case, but it would
> be an interesting experiment.
>
> > Shouldn't we measure how much work-effort increased and then see if
> > there's still a productivity difference that requires explanation?
>
> Granted. This is a fair question and should be captured in a
> pair-programming study.
> There is, apparently, a IEEE-CS paper available describing a framework for
> conducting Pair Programming research.
> (http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/proceedings/&toc=comp/proceedings/isese/2003/2002/00/2002toc.xml&DOI=10.1109/ISESE.2003.1237972)
>
>
> >
> > They could have sold pair-programming to management on the basis that
> > each one of the pair acted as a supervisor that kept the other working
> > harder :-)
>
> Perhaps. Do you think that this is likely?

For Theory X managers this argument would be supported by their
existing beliefs. (Obviously not the argument to use with Theory Y
managers.)

>
> >>
> >> >
> >> > Why aren't we told the error rate for the remaining three components?
> >>
> >> I'm guessing it is because the author is a true believer and wanted to
> >> skew
> >> the paper towards Pair Programming, yet the teams working on these
> >> components didn't do a good job of measuring their observed error rates,
> >> so
> >> he was forced to rely on empirical data. (e.g. He asked them if they
> >> were
> >> seeing fewer errors, and they said "significantly less").
> >
> > afaik "empirical" doesn't exclude measurement. (I had the notion that
> > most of Science was empirical.)
>
> My bad. I meant to say "anecdotal."
>
> >> That said, I haven't found a single study or paper, even at this level,
> >> where someone experimented with pair vs. solo programming and found solo
> >> programming to be measurably more productive.
> >
> > Shouldn't we be comparing pair programming with partner programming? Is
> > collaborating to get the project done more abnormal than working in
> > splendid isolation?
>
> You may be interested in this paper, submitted to OOPSLA:
> http://www.simula.no/departments/engineering/publications/SE.5.Gallis.2002

Yes, that's what I had in mind :-)

> According to the abstract, the researchers noted some resistance to moving
> towards pair programming on the part of experienced programmers, resistence
> that was not as pronounced for inexperienced programmers. It does not
> appear to be a comparison of productivity rates. Regardless, this is the
> ONLY paper I could find that attempted to describe (but does not appear to
> baseline) the "partner programming" style of software development
> interaction. Perhaps the reason that no one has made the comparison you
> suggest in a statistically sound manner is because there does not appear to
> be any better definition of "partner programming" than of "pair
> programming."
>
> In other words, the field is wide open... feel free to define and
> parameterize "partner programming" as an alternative to "pair programming."
>
>
> --
> --- Nick Malik [Microsoft]
> MCSD, CFPS, Certified Scrummaster
> http://blogs.msdn.com/nickmalik
>
> Disclaimer: Opinions expressed in this forum are my own, and not
> representative of my employer.
> I do not answer questions on behalf of my employer. I'm just a
> programmer helping programmers.
> --

.

Relevant Pages

  • Re: XP and Pair Programming
    ... >>> In other studies of pair programming is any increased productivity ... correct in stating that any excerpt runs the risk of being interpreted out ... >> In my personal experience with pair programming, ...
    (comp.object)
  • Re: XP and Pair Programming
    ... >>> experiment of using pair programming, ... he did state that the productivity and error ... > the productivity and error rates broke even. ...
    (comp.object)
  • Re: XP and Pair Programming
    ... >> experiment of using pair programming, ... >> "We hoped for a productivity gain of anything greater than 0 percent. ... the productivity and error rates broke even. ...
    (comp.object)
  • Re: [EGN] turing completeness
    ... > about programming. ... In Pair programming, two developers work on code mutually. ... Most recently I overhauled a Source Safe library with another ... some workplace control to the actual employees. ...
    (comp.programming)
  • Re: XP and Pair Programming
    ... > Better to poll readers of a general purpose programming magazine. ... > "We hoped for a productivity gain of anything greater than 0 percent. ... Another excerpt: ...
    (comp.object)