Re: XP and Pair Programming

On Tue, 30 Aug 2005 17:17:38 GMT, "H. S. Lahman"
<h.lahman@xxxxxxxxxxx> wrote:

>Ah, the old BDUF argument paraphrased! When in doubt trot out the
>mantras, complete with capitals for emphasis. B-) [Every time I talk
>to XP people I feel like I have been thrust back to the '60s and a
>Flower Child is going to stick a flower in my pocket protector. B-))
>Sorry, I couldn't resist it; the Devil made me do it.]
>
>Like waterfalls, the difference between your "static" The Review and
>pair review is a matter of scale, not some fundamental philosophical
>difference. The fact that those activities are combined with
>development in a process in a particular way does not change the nature
>of the activities. Nor does it change the "static" positioning of those
>activities at a location after doing something else in the process.
>
>IOW, you can't review anything that hasn't been done yet so that fixes
>the review statically in time relative to other development steps.
>Whether the review subject matter is a subsystem, a module, or a code
>fragment is just a matter of scale. Nor is it dependent on the
>mechanics of the number of people, how changes are managed, etc.. The
>basic review activity is the same and it is always statically positioned
>relative to other activities.

Well, H (can I call you H?), I've done a lot of classical-style
reviews, and a lot of pair programming, and there's more going on than
just scale in my opinion. Here are some examples:

CLASSICAL REVIEW

CODE BAKED. In the classical review, the code is baked. The
programmer has completed it, or nearly so. The reviewers (and there
are often more than one) have not seen the code come into existence:
they see it statically. They do not understand why it is the way it
is, and the usual practice in reviews is that the developer does not
explain how the code got that way.

FEW BIG DISCOVERIES. I have only rarely seen any significant changes
to code come out of reviews. This happens in the rare cases where the
spec was totally misunderstood, or when the programmer chose a really
obviously horrible approach.

PERFUNCTORY. In practice, I've seen reviews become almost perfunctory.
You come in, you point to a bad variable name or a coding standards
violation, you wait for everyone else to point out theirs, then you
leave. I've seen preparation for reviews be equally perfunctory.
People will come back to lunch at 1230, to prepare for a review at 1,
things like that. Even in a shop that values reviews, it's easy to lay
back.

SMALL BUGS HIDE. Code reviews, while much better than not having
reviews, tend to miss small bugs, because they hide in the weeds of
the bulk of the code.

PAIR PROGRAMMING

CODE NOT BAKED. In the pair programming situation, you're there while
the code comes into being. You see why it is the way it is, and more
important, you influence it before it's baked, while it's still
malleable in the mind of the owner.

MORE BIG DISCOVERIES. Because the code isn't baked, and because the
algorithm is visible to the "reviewer" early on, algorithmic mistakes
will often be caught sooner, before anyone is committed to them.

CANNOT BE PERFUNCTORY. In a shop that values pair programming, it's
hard to lay back. It's just you and the person with the keyboard --
and half the time you ARE the person with the keyboard. The result, in
my experience, is that the pair is more engaged than in a static
review, both because he's actually developing at least part of the
code, and because if he isn't paying attention, the snoring noise will
alert the programmer.

SMALL BUGS CAN'T HIDE. In pair programming, you see each line coming
into being, each little loop. You're watching the details. As such,
you're more likely to notice the small errors.


I think the bottom line is this: pair programming has some of the
aspects of reviewing, but they are simple not the same thing at all.
In the one, a group of one or more people inspect the code after it's
essentially done. In the other, two people are simultaneously engaged
in crafting each line of the code.

It's kind of like watching the game, or being in the game.

Regards,

--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
.

Relevant Pages

  • Re: XP and Pair Programming
    ... But the techniques are no different than those employed in pair programming to identify errors, bad coding practices, blind spots, and whatnot. ... If you can do it in a pair situation you should be able to do it in any review situation. ...
    (comp.object)
  • Re: Slow DOWN, please!!!
    ... that and if you hope for more people doing code review - put down your ... possible bugs in that area; ... about data structures, ... realistically revert in such situation - not without very massive work. ...
    (Linux-Kernel)
  • Review of the new Symbolic toolbox included with MATLAB 2008b
    ... Thanks for your Review. ... I am very pleased that you write you "collect bugs in computer ... TI-Nspire, xCAS, Maxima, MATLAB. ... Was is your intention not to put any MATLAB's Symbolic Toolbox ...
    (comp.soft-sys.matlab)
  • Re: NASM 0.98.39 vs. NASM 2.03.01 disassembly
    ... fixed bit size: an unsigned integer. ... irritating bugs) and more related to the actual problems that the ... At some later date, the programmer had a different mindset, different ... having several people review the code is a good thing. ...
    (alt.lang.asm)
  • Re: Is this list still active?
    ... >monastic review process that takes top people. ... I don't quite share your optimism, and neither does the OpenBSD team. ... make it harder to exploit many classes of bugs. ... Oh, absolutely, but code review should be the last step in a lengthy, ...
    (SecProg)