update to http://www.pairprogramming.com , please

[Gerold Keefer]

hello *,

in the past there was some discussion on the productivity and
quality gains achieved by pair programming.

Markus Mueller of the University of Karlsruhe has published
the results of an experiment that compares classical programming
and reviews to pair programming, titled
"Are Reviews an Alternative to Pair Programming ?"
at
http://www.ipd.uka.de/KarHPFn/papers/ease03.pdf .

although the evidence is not too strong and the experiment is
located in a non-industry environment, it indicates that pair
programming is less efficient. a key sentence is

"If we combine this result with the result of the
reliability analysis, we have to say that the single
programmers developed programs with comparable quality
but with fewer cost as compared to developer pairs."

best regards,

gerold

[John Roth]

"Gerold Keefer" <gkeefer@avoca-vsm.com> wrote in message
news:3EFDB512.A4EB6930@avoca-vsm.com... hello *, in the past there was some discussion on the productivity and quality gains achieved by pair programming. Markus Mueller of the University of Karlsruhe has published the results of an experiment that compares classical programming and reviews to pair programming, titled "Are Reviews an Alternative to Pair Programming ?" at http://www.ipd.uka.de/KarHPFn/papers/ease03.pdf . although the evidence is not too strong and the experiment is located in a non-industry environment, it indicates that pair programming is less efficient. a key sentence is "If we combine this result with the result of the reliability analysis, we have to say that the single programmers developed programs with comparable quality but with fewer cost as compared to developer pairs." best regards, gerold

I did a quick runthrough of the study, and while
it seems to have been well done, it's basically
irrelevant to the subject of XP. It might have some
relevance to using pair programming in an different
process, although see my additional comment below
on the two sections being at different points on
the learning curve.

The reason is that pair programming in XP is part
of a package of practices, which include test driven
development, refactoring and having the acceptance
tests availible during the development process.

The experimenter says explicitly that none of the
other extreme programming techniques were
included in the experiment; furthermore, the
introduction to pair programming was a 1.5 hour
unit of unknown content (it would make a huge
difference if it was behavioral as opposed to
lecture, for example.)

The subjects were all college seniors (US equivalent)
with an average of six years of experiance; several
of them had experiance with reviews, but only one had
any experiance with pair programming. I would normally
expect it to take some time for anyone to find a personally
optimal way of using a new technique; I don't see that
addressed in this study.

Conclusion: it joins the growing pile of studies
under the "unclear on the concept" sign.

John Roth

[Gerold Keefer]

John Roth wrote:
I did a quick runthrough of the study, and while it seems to have been well done, it's basically irrelevant to the subject of XP.

certainly and exactly this is why i stated
http://www.pairprogramming.com
and not
http://www.xprogramming.org .
however, this instant, not asked for reaction lets me venture
that it might have relevance for XP, too.
It might have some relevance to using pair programming in an different process, although see my additional comment below on the two sections being at different points on the learning curve. The reason is that pair programming in XP is part of a package of practices, which include test driven development, refactoring and having the acceptance tests availible during the development process.

aha, the magic comes from the whole package made up
of dysfunctional or non-benificial parts. for an interesting
experiment on TDD or test-first, have a look at
http://www.ipd.uka.de/KarHPFn/papers/ease02.pdf .
you will read at the bottom:

"Test-first pays off only slightly in terms of increased reliability.
In fact, there were five programs developed with test-first with a
reliability over 96% compared to one program in the control group.
But this result is blurred by the large variance of the data-points.
Concentrating on the program versions after the implementation-phase,
the result just turns around. The test-first group has signifcantly
less reliable programs than the control group. So far, we do not know,
if this effect is caused by a false sense of security, less importance
of the acceptance-test for the test-first group, or if it is quite
simply a
result of too little testing."
The experimenter says explicitly that none of the other extreme programming techniques were included in the experiment; furthermore, the introduction to pair programming was a 1.5 hour unit of unknown content (it would make a huge difference if it was behavioral as opposed to lecture, for example.)
The subjects were all college seniors (US equivalent) with an average of six years of experiance; several of them had experiance with reviews, but only one had any experiance with pair programming. I would normally expect it to take some time for anyone to find a personally optimal way of using a new technique; I don't see that addressed in this study.

your agrument holds true for PP *and* the review technique.
this is a clear 1:1, hot air contribution.
Conclusion: it joins the growing pile of studies under the "unclear on the concept" sign.

that's your respected opinion. given the fact that you managed
to mix up a lot of concepts in a short comment and contributed
essentially only redundancy to the discussion, a "thought-last" sign
is my judgement on your posting.
John Roth

regards,

gerold

[Paul Campbell]

"Gerold Keefer" <gkeefer@avoca-vsm.com> wrote in message news:3EFDB512.A4EB6930@avoca-vsm.com... hello *, in the past there was some discussion on the productivity and quality gains achieved by pair programming. Markus Mueller of the University of Karlsruhe has published the results of an experiment that compares classical programming and reviews to pair programming, titled "Are Reviews an Alternative to Pair Programming ?" at http://www.ipd.uka.de/KarHPFn/papers/ease03.pdf . although the evidence is not too strong and the experiment is located in a non-industry environment, it indicates that pair programming is less efficient. a key sentence is "If we combine this result with the result of the reliability analysis, we have to say that the single programmers developed programs with comparable quality but with fewer cost as compared to developer pairs." best regards, gerold


I think the study is unrepresentative to the extent that figuring out algorithms is actually
only about 5% of the activity of typical commercial programming - the rest is to do with
issues of design, readability, and structure. IME pair programmning doesnt help too much
with the figuring out complex algorithms bit, but helps a hell of alot with the other
95%. The weakness of reviews is that for any non-trivial system only the original coder
has a complete understanding of what has been written and the reviewers are generally
relagated to commenting on superficial issues of style and nitpicking minor coding standards
transgressions.

Paul C.