Re: Work to the risk was Re: Inspections Was: RE: [AM] ANN: Mashing Deadly My

(responding to Scott P)

>| > | (Scott A)
>| > | ...  If I was working on truly critical 
>| > | software where a mistake is costly ... then I'd very likely 
>| > | insist on reviews and inspections.  In these situations the risk far

>| > | outweighs the cost.  In the vast majority of situations this isn't
the 
>| > | case [where other ways] seem to result in very high quality work 
>| > | anyway.
>| > 
>| > (Scott P)
>| > If you're willing to limit your scope to projects where it doesn't
>| > matter if you deliver defects, then I can agree with you.  
>| 
>| (J.B.)
>| This is insulting. It ignores Scott A's argument entirely.
>
> (Scott P)
> Scott A said "truly critical...where a mistake is costly...where the
> risk far outweighs the cost".  My restatement is in line with that
> statement. It wasn't meant to be insulting, just to be stark.
> Scott A is saying, specifically, that these methods apply where
> the cost of releasing the defects that inspections would catch is
> lower than the cost of doing the inspections, which is exactly what
> I would say, too.  I don't think "doesn't matter" is an inaccurate
> characterization of that rule - if the defects mattered more than
> the cost, you would do the inspections.

You did seem to ignore the second half of Scott Ambler's 
comment, that the processes used "seemed to result in very
high quality work anyway".

I think we can accept your point that code inspections would be
omitted when the value they give would not justify their cost.
I have worked on software (proof of concept prototypes)
where high quality was not important.  Yet there are other cases
where inspections are not justified, such as the case Scott
Ambler outlines - the code is already of very high quality.

Not all teams doing XP or other agile approaches manage to 
achieve this "very high quality", but some teams have reported
exceptionally high quality.  Whatever approach, to achieve high 
quality code needs high quality people, and after that, the choice
is in how you leverage them to deliver high quality code.


>| This is equally insulting. I'm not sure that this furthers your 
>| argument. No need to puff out your chest at us.
>
> Agilists, of course, never puff out their chests and demean
> people who use traditional methods...

Let's quit while we're even...


> If you're dealing with people's money or building tools that people
> will depend on in earning their money or building consumer devices
> or dealing with personal data whose release or mis-reporting could
> expose you to liability suits, you ARE working on software that is "truly
> critical...where a mistake is costly", and you should be using
> appropriate methods. I don't think that's a small niche, and I think
> it's misleading to describe it in ways that imply that it is.

Of course, my personal belief is that we should *always* use
appropriate methods.  The question is, when is it appropriate to
use inspection?  Clearly, the answer is, when you cannot be
sure of getting adequate code quality without inspection, and
as a result the value of inspection would be greater than the cost
of inspection.  That assumes, of course, that doing inspection
*would* improve the quality of code to a sufficient degree.

Yet the key improvement is in getting better people faster, as
the quality of code depends on the quality of people, whether the 
quality is achieved by peer review at pairing or by peer review
at inspection.  I would suggest that peer review at pairing is more
effective at making the team better faster, because there is 
immediate feedback not only on the code, but also on the design,
testing and thought processes that go into producing the code.
Inspection gives late feedback, and only on the finished product.

IOW, if you have access to people of quality sufficient to review
code, you may find it is more effective to use them to produce
the code and mentor the rest of the team in the process.


Paul Oldfield

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
www.aptprocess.com

any opinions expressed herein are not necessarily those of
Mentors of Cally or the Appropriate Process Movement
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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