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

| From: "J. B. Rainsberger" <[email protected]>
| 
| 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.
---

Yes, but reference books don't help if the people involved think they
know the answer or don't recognize that the issue is on the table at
all.  This would seem likely to be more prevalent in an environment
where writing documentation is actively resisted.  I was trying to find
an obvious instance of a problem that in practice is subtle. The issue
is more likely to be "Will component Y respond correctly if component X
hasn't already called component Y's abc() method and the system
configuration option QRM was set to "OFF"?", and the problem is likely
to be that neither of the pair knows that that set of circumstances
is interesting, so neither raises the question explicitly.

The hope is that by using 5 pairs of eyes in an inspection, it is more
likely that some inspector will be aware of an issue that affects the
way the code is written or will have seen a similar problem and be
prepared to raise it as a question even if she isn't sure of the answer.

---
| <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."
---

We usually consider "thinking together" to be likely to lead to
blindspots.  The reason the author misses many defects is that his view
is clouded by his intentions; if the pair shares the intentions, then
they may both have the same blindspots.

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

Your nature is apparently different from mine - I'm just as likely to
argue with a co-author as with a reviewer. An inspection also has a
moderator, who is specifically charged with making sure that we don't
take the group's time arguing, but track the issue and move on.

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

I don't see anything in the agile methods I've read about to suggest
that you go back to look at code that isn't otherwise being opened up
for review.  That is, unless you're adding a feature that affects a
module or doing a refactoring that affects the module, the module would
remain just as frozen in an agile method as in a traditional method.


I would expect most projects to have "central" nodes that change a lot
as additional features are added and "leaf nodes" that are written once
and never changed unless they break, even in an agile methodology.

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

I wouldn't want to be read as being opposed to pair programming.  I have
done it (and enjoyed it) and I DO believe that it improves quality and
produces results faster and with less effort than independent
development.  I also believe that test-first is a best practice and will
also improve quality and help produce results faster and with less
effort. However, the numbers I've seen so far convince me that the two
together still don't remove enough defects to justify not doing
inspections in any situation where there is significant cost associated
with defects.

As noted elsewhere, if you limit your scope to situations where the cost
of defects is low and it is easy and cheap to get a new release into
service when a defect is fixed, then you may be justified in not doing
inspections.  I just wish the methodologists would use larger type in
their disclaimers...

scott

-- 
scott preece
motorola urbana design center (il67), 1800 s. oak st., champaign, il  61820  
e-mail:	[email protected]	fax:	217-384-8550
phone:	217-384-8589	cell: 217-433-6114	pager: [email protected]

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