The goal is capturing just enough in the comments to identify common issues, and so the code/doc owner can understand the reported issues (perhaps weeks or months later).

Best wishes,
Bernie

I would like to understand how does it benifit a project team or an organization capturing the code review/ doc review comments?

Thanks & Regards,
Madhura

Sometimes terminology can help clarify a point. The practice I described here as a review would be more accurately described as an inspection, the purpose of which is defect removal. The benefits you describe are usually conferred by a “walkthrough”. Unfortunately, both these types of meetings get lumped together under the ambiguous category of “review”. My workflows usually contain at least one walkthrough, in addition to an inspection. Efficient walkthroughs might be a good topic for another article!

* the visibility issue mentioned above — people might always catch the most obvious bugs, in the same way that trappers will catch the animals most likely to get trapped (gullible, less cautious, hungrier for the bait, etc.)

* as you say, “The trick to making the population estimate work is the statistical independence of the samples.” If two programmers have very similar approaches to smoking out bugs, the results will be akin to two biologists who tend to place traps in similar areas.

But I want to vigorously disagree with your final paragraph. Your thesis statement: “There really is only one legitimate purpose for a code review: to find defects.” is simply false. Finding defects is ONE benefit of performing code reviews, but it is one of the more minor benefits.

Bigger benefits include: (1) increased communication among team members: they actually talk about the code to each other, forcing people to describe and defend their commonly used idioms and practices, (2) mentoring opportunities, (3) increasing reuse due to awareness of different parts of the code: if you’ve never seen a piece of code, how likely are you to reuse it; conversely if you’ve code reviewed something you’ll likely remember it the next time you need that subroutine, (4) no piece of code ever languishes unmaintainable because only a single developer understands how it works. There are other benefits (mostly centered around communication and understanding), but this gives you the flavor.

I DO agree that beyond a certain point code reviews are no longer improving communication and they can become “expensive and bureaucratic”. The solution is the same one that fixes “carpenter’s thumb”: if it hurts (isn’t benefiting the code or the team), then *stop doing it*!

Paul.