Re: Inspections Was: RE: [AM] ANN: Mashing Deadly Myths

Responding to two at once.

At 02:17 PM 2/24/2004, Paul wrote:
>From: Scott Ambler [mailto:[email protected]]
>Sent: Tuesday, February 24, 2004 9:15 AM
> > Inspections are great compensatory practice
> > when you're not able to adopt practices such
> > as collective ownership, coding/modeling standards,
> > continuous integration, and pair programming/modeling
> > with others.
>
><snip>
>
>IMO, inspections (or reviews) cannot be replaced by any of Scott's
>suggestions,

Have you tried them first?


>  although those practices will likely lower the chances of
>anything untoward coming out of an inspection.

Yes, that's my experience.  Then after running a few inspections where very 
little is produced, eventually people start to clue in and say "hey, we're 
wasting our time with this" and you come to the conclusion that you should 
drop them.  Try it and see for yourself what happens.


>  However, a *team* can
>incorrectly design a software solution. Collective ownership or pair
>programming won't prevent a "team error" from happening, especially if the
>project on the cutting-edge of technology.

Yes, and the reviewers can incorrectly ding you for issues that they don't 
understand or simply would do another way.



>OTOH, if done, they [inspections/reviews] must be done by a third-party not
>emotionally, intellectually or otherwise invested into the current codebase.
>This third-party could be another group inside the company, or perhaps
>outside. Hopefully, the next goes without saying but, for the sake of
>maintaining agility, it is important to recognize that not all projects
>require this level of scrutiny. I'd use reviews, *with* the above practices
>that Scott limits himself to, on the projects that call for it.

I don't limit myself at all.  When I'm at a new client I'll often use 
reviews/inspections to compensate for communication barriers that I can't 
remove.  I'll also use them in conjunction with the techniques that I list 
if the client insists on it, then I wait for them to figure out that the 
inspections aren't adding much value.



>What some often miss is that one should see inspections as a "second
>opinion" mechanism.

As J.B. pointed out, pair/team promiscuously.  If an outsider's opinion 
would actually seem valuable in some cases, for example someone might have 
expertise at a certain part of the architecture, then I'd try to get them 
actively involved with the appropriate part of the project.  If they're 
available for an inspection then surely they're available for a design 
meeting long before that.

><snip>

At 05:51 PM 2/24/2004, Scott P. wrote:

>| From: "J. B. Rainsberger" <[email protected]>
>|
>| Scott E. Preece wrote:
>|
>| > The purpose of inspections is defect removal.  Pairing will remove SOME
>| > of the defects that an individual programmer would leave in the code,
>| > but not all of them.  For example, University of Utah study that
>| > Cockburn and Williams cite in "The Costs and Benefits of Pair
>| > Programming" found that pairs left 15% fewer defects in their output
>| > than individual programmers.
>|
>| This study does not account for promsicuous pairing over time, and
>| therefore is unfairly compared to inspections "by multiple inspectors."
>---
>
>Since promiscous pairing still doesn't assure that more than two pairs
>of eyes look at any particular part of the code, there's no particular
>reason why it would improve performance in finding defects in any
>particular piece of code.

Anecdotal evidence appears to point to the contrary.  I suspect we'll soon 
see studies which show this.  Perhaps you should post this question to the 
XP list because someone might know of unpublished (or recently published) data.

- Scott


====================================================
Scott W. Ambler
Senior Consultant, Ronin International, Inc.
www.ronin-intl.com/company/scottAmbler.html

www.agiledata.org
www.agilemodeling.com
www.ambysoft.com
www.enterpriseunifiedprocess.info
www.modelingstyle.info
www.ronin-intl.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: [email protected]

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: [email protected]

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------