Re: XP and Pair Programming

Responding to Martin...

Reviews are very costly if done correctly. Reviewing a module that
took 5 hours to write should require 5 hours. If you have two or
three people doing the review, you have a very high overhead.

While I agree that there is no free lunch and reviewer effort is significant, especially in aggregate, I can't agree with the 1:1 metric per reviewer. It is much easier to critique something with intellectual content that already exists than it is to create it. I've reviewed specs, models, and code that took days or weeks to create with a few hours effort on my part.

Also, one can manage complexity for reviews. For example, before we did translation we did code reviews. However, we determined that the benefit (in terms of reliability) did not justify the effort cost. So we adjusted by doing full code reviews on a random sampling basis (mainly to communicate best practices) and just reviewed the rest for conformance to standards. We also commonly focused reviews (e.g., reviewers A, B, and C would only evaluate architecture issues while D and E might evaluate performance issues).

Another mitigating issue is the sort of problems one targets. If one is looking for big problems that might entail major rework, then one is better off with shallow reviews more often by more people. That's because one is looking for big blind spots in the design and finding them is more dependent on having a different perspectives than the level of review effort.

I am also bothered by the notion of review time being "overhead". In an accounting sense that might be true, but review effort is just as directed towards product quality as, say, testing. IOW, it is part of daily development work. Like other development activities, in the end one needs to justify what one does with hard data. So one should collect data on the effectiveness of reviews and, if necessary, adjust what is reviewed and/or how it is reviewed. But once the benefit is established it is part of the job description.

I think its better to pair often, than to pair infrequently.  I don't
think 100% pairing is wise though.  There are tasks for which pairing
is a waste.

I agree some things are better done individually. But hopefully every work product gets reviewed somewhere along the line before the product ships. B-)


*************
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: XP and Pair Programming
    ... >Responding to Martin... ... >> Reviews are very costly if done correctly. ... >we adjusted by doing full code reviews on a random sampling basis ... That's also a common approach. ...
    (comp.object)
  • Re: Words and their meanings
    ... But it's not my dog. ... Code reviews don't matter if the _design_ is stupid. ...
    (alt.sysadmin.recovery)
  • Re: Words and their meanings
    ... caught late in the cycle cost a lot more than errors caught in a review. ... But it's not my dog. ... Code reviews don't matter if the _design_ is stupid. ...
    (alt.sysadmin.recovery)