Re: XP and Pair Programming

"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?

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?

>>
>> >
>> > 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
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
    ... >>> 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
    ... > correct in stating that any excerpt runs the risk of being interpreted out ... >>> In my personal experience with pair programming, ... > input to the productivity formula. ... > conducting Pair Programming research. ...
    (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)