Re: XP and Pair Programming

Responding to Phlip...

Does that say I'm incompetent to review? or that reviewing is a diversity-challenged technique?

There is no doubt that reviewing other people's work is a learned skill.


Thank you for identifying the third option ;-)

I don't see it as an option. The skill has to be there regardless of the nature of the review.

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.

Actually finding bugs is best done by having multiple screens, even when coverage overlaps. IOW, a review is just a form of test. Each view of the application represents a different screen for review purposes so the more views there are besides the code itself, the more reliable the application will tend to be. Those views also provide the different perspectives that you seek.


This discussion neglects one terrific and completely anecdotal aspect of pairing. Naturally, the odds of resulting bugs goes down. However, the rate at which one pair exclaims and points, "Ooh, there's a bug!" goes way down too.

You are going to have to put more words around this. It seems to me that the ability to identify errors, bad practices, etc. effectively in other's or one's own work has, at most, a very tenuous relationship to the mechanics of the review process.

[OTOH, the review subject matter can make a big difference for certain types of problems. For example, it is much easier to find fundamental design problems in a UML model than in 3GL code simply due to the relative compactness and level of abstraction but a UML model is pretty inefficient for identifying dependency management problems.]


To leverage our synergies, the learned reviewing behavior is of course very important. (Kelly and Brad paired all day, then I land on their design like a hawk landing on a rabbit, and kick its guts out with one sweep of my talons.) In terms of teamwork, I review what I know how to, and others review what they know how to.

That's just a matter of applying the correct review mechanics for the subject matter in hand. If such specialization works for a given environment, then fine. IOW, it is really a process issue.


The spontaneous bug-suppression effort is very important, and part of pair programming's full effect. I don't think it's transferable to review-last. 

I don't know what you mean by "review-last".


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH



.

Relevant Pages

  • Re: warning: massive change to conditional coding style in net?
    ... David Miller wrote: ... the patch will be cleaner. ... clean patches are easier to review. ... I've followed existing coding practices. ...
    (Linux-Kernel)
  • 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)