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

Scott E. Preece wrote:
<snip />
> On the other hand, if the question is "Does the compiler automatically
> promote type A to type B?", then either somebody in the group knows the
> answer or nobody does.  Adding people does increase the probability that
> somebody will know the right answer, but only linearly.

But that's why God gave us reference books. Looking up facts doesn't 
require anyone but one person willing to use Google or walk to a 
library; that kind of thing is not interesting in any event. Those 
aren't the kinds of issues that motivate you /one way or the other/ to 
work alone or in a group.

<snip />
> It also isn't clear that having both pairs of eyes looking at the code
> together is more effective at defect removal than having one write it
> and the other read it after the fact.  

It is clear to me through personal experience, for two reasons.

1. If the "inspector" is involved in writing the code with me, then he 
better understands my intentions, and so is more likely to identify 
something as a defect. Later, not knowing all my intentions, he may see 
the same thing as merely "another way to do it."

2. If the "inspector" points out the defect immediately, I remove it 
immediately. If he points them out after I think I've finished, then I 
will attempt to defend the code as is, and begin doing things like 
prioritizing defects, rather than just fixing them.

You may argue that in #2 I am "being lazy," but I claim it is "human 
nature." The less we go against human nature, the better.

 > As mentioned in a previous
> posting, the reported numbers for defect reductions from using pair
> programming are toward the low end of typically reported numbers for
> single-reader inspections.  This wouldn't be surprising - the single
> inspector has no other opinion to defer to, a member of a pair may not
> raise an issue because she thinks the other member knew what she was
> doing.  If you've got two people working together and they have
> different answers to a given question, there's a non-zero probability
> that the one favoring the wrong answer will convince the one who
> actually knew the right answer, rather than vice versa.

Agreed, however, this seems to assume that we only get "one bite at the 
apple." With promiscuous pairing, design improvement and defect removal 
occur on an ongoing basis; whereas inspections seem to be used more in 
an environment where once a task is done, the code is frozen and 
possibly even forgot. Also, an Agile team uses tests for defect 
/avoidance/ (rather than removal), so perhaps we're barking up the wrong 
tree, anyway.

Perhaps PP is not as effective as inspections for defect removal; but 
that's why we have tests. Also, PP /more easily/ motivates programmers 
to /change code/ in response to problems, rather than just say "oops, 
but I don't have time to make the changes." or "I'll just make these 
three easy changes." /That/ is the power of PP (real-time inspection) or 
after-coding inspections.
-- 
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: +1 416 791-8603
Let's write software that people understand

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
--^----------------------------------------------------------------