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

"J. B. Rainsberger" <[email protected]> Wed, 25 Feb 2004 11:01:24 -0500
Newsgroups gmane.comp.programming.modeling.agile
Message-ID <[email protected]>
Scott E. Preece wrote:

> | From: "J. B. Rainsberger" <[email protected]>
> | 
> | Scott E. Preece wrote:
> | 
> | > | From: Scott Ambler<[email protected]>
> | > | 
> | > | It's the same thing with software.  If I was working on truly critical 
> | > | software where a mistake is costly, perhaps the control software for the 
> | > | Mars Lander or control software for a medical device, 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, and frankly it makes very little sense to do inspections and reviews 
> | > | when other practices such as pair programming, modeling with others, 
> | > | collective ownership, ... seem to result in very high quality work anyway.
> | > ---
> | > 
> | > 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.  
> | 
> | This is insulting. It ignores Scott A's argument entirely.

I overreacted. Withdrawn. The fingers went too quickly.

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

In that context, I can't argue. See above.

> Agilists, of course, never puff out their chests and demean people who
> use traditional methods...

I was talking about you, and not about some other group of people. When 
they puff their chests at me, I let them know, too.

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

I guess I wasn't clear on "costly." If "costly" means "bankrupt" or 
"dead," then my attitude changes considerably. :) My observations 
include two key recurring patterns that have shaped my point of view.

1. Continually overestimating the ROI on inspections, usually by 
overestimating the cost of defects /or/ underestimating the defect 
removal capability of the other XP practices.

2. Paying lip service to inspections with a low "fix rate," that is, 
using inspections to uncover problems but not taking the time to 
actually fix them. This is just like testing in the last three weeks of 
the project, then management saying, "We can't afford to fix that problem."

I have to see inspections be used appropriately before I can believe 
their value. I haven't had that experience yet.

Pardon me, and no hard feelings.
-- 
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
--^----------------------------------------------------------------