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

[Scott E. Preece]

| From: Scott Ambler<***@ronin-intl.com>
|
| 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. I've never
actually worked in such a domain, but when I write code for my own use
I wouldn't bother with arranging inspections, I would just fix problems
when they became too irritating to live with. My perceptions are
colored by working with software delivered to customers, with both real
costs and credibility costs to escaped defects.

scott
--
scott preece
motorola urbana design center (il67), 1800 s. oak st., champaign, il 61820
e-mail: ***@urbana.css.mot.com fax: [phone]
phone: [phone] cell: 217-433-6114 pager: ***@msg.myvzw.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

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

[J. B. Rainsberger]

Post by Scott E. Preece
|
| 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.

Post by Scott E. Preece
My perceptions are
colored by working with software delivered to customers, with both real
costs and credibility costs to escaped defects.

This is equally insulting. I'm not sure that this furthers your
argument. No need to puff out your chest at us.
--
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: [phone]
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: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

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

[Scott Ambler]

Post by Scott E. Preece
|
| 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. I've never
actually worked in such a domain, but when I write code for my own use
I wouldn't bother with arranging inspections, I would just fix problems
when they became too irritating to live with. My perceptions are
colored by working with software delivered to customers, with both real
costs and credibility costs to escaped defects.

I have no doubt that it may be different for delivering software to cell
phone handsets because you clearly have some update challenges if you get
it wrong.

However, this often isn't the case with the vast majority of business
software, you can in fact redeploy it relatively easy if you choose (many
orgs choose to make this overly complex, but they don't actually need to).

BTW, I have been known to deliver working software to customers. ;-)

- Scott

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

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

[Scott E. Preece]

| From: "J. B. Rainsberger" <***@rogers.com>
|
| Scott E. Preece wrote:
|
| > | From: Scott Ambler<***@ronin-intl.com>
| > |
| > | 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.
---

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.

---
| > My perceptions are
| > colored by working with software delivered to customers, with both real
| > costs and credibility costs to escaped defects.
|
| 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...

My statement was not meant to be insulting in any way, it was meant to
indicate why I believe Scott's statement understated the issue. Many of
us work in environments where the cost of user-visible defects is
potentially bankrupting, even if not life-threatening. It's very
important to understand the scope of your advice, and a lot of the agile
literature does just what Scott did - using examples like the Mars
Lander and medical devices that will imply a very small niche to their
readers.

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.

scott
--
scott preece
motorola urbana design center (il67), 1800 s. oak st., champaign, il 61820
e-mail: ***@urbana.css.mot.com fax: [phone]
phone: [phone] cell: 217-433-6114 pager: ***@msg.myvzw.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

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

[J. B. Rainsberger]

Post by Scott E. Preece
|
|
| > |
| > | 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.

Post by Scott E. Preece
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.

Post by Scott E. Preece
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 />

Post by Scott E. Preece
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 :: [phone]
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: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

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

[Scott E. Preece]

| From: Scott Ambler<***@ronin-intl.com>
| Date: Wed, 25 Feb 2004 09:30:24 -0500
|
| At 08:49 AM 2/25/2004, you wrote:
|
| >| From: Scott Ambler<***@ronin-intl.com>
| >|
| >| 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. I've never
| >actually worked in such a domain, but when I write code for my own use
| >I wouldn't bother with arranging inspections, I would just fix problems
| >when they became too irritating to live with. My perceptions are
| >colored by working with software delivered to customers, with both real
| >costs and credibility costs to escaped defects.
|
| I have no doubt that it may be different for delivering software to cell
| phone handsets because you clearly have some update challenges if you get
| it wrong.
|
| However, this often isn't the case with the vast majority of business
| software, you can in fact redeploy it relatively easy if you choose (many
| orgs choose to make this overly complex, but they don't actually need to).
---

I think you implied an exactly appropriate rule - if you're satisfied
that the risk from not doing inspections is lower than the cost of doing
them, then don't do them. I think we may disagree about what percentage
of software falls on which side of that line, but it's really a
project-specific issue, so are opinions are irrelvant. My concern is
just that bringing in outlier examples (like the Mars Lander) leads
readers to assume their projects, being more mundane, are safe and that
they don't need to do that risk analysis. Many mundane software projects
deal with other people's money, time, or risk than might be obvious.

---
| BTW, I have been known to deliver working software to customers. ;-)
---

I certainly didn't mean to imply anything else! I like Agile Modeling a
lot and agree with most of what you recommend, and wouldn't want to lose
sight of that in pushing back on a few specific points and statements.

scott
--
scott preece
motorola urbana design center (il67), 1800 s. oak st., champaign, il 61820
e-mail: ***@urbana.css.mot.com fax: [phone]
phone: [phone] cell: 217-433-6114 pager: ***@msg.myvzw.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

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

[Scott E. Preece]

| From: "J. B. Rainsberger" <***@rogers.com>
|
| 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 completely agree. An organization should have a good picture of what
it costs to fix defects at each phase of development, and when defects
are reported, they should include an estimate of the cost of fixing the
specific problem in deciding whether/when to fix it. The organization
should also have a good understanding of the potential costs of shipped
defects - how much it would cost to re-release and what the potential
liability issues are for different kinds of product failures.

It's important to understand that we are a litigious society. It is
COMPLETELY possible to be sued for large amounts of money if you make
alarm clocks and somebody suffers a loss as a result of your alarm clock
failing to go off when it was supposed to.

Typical inspection process definitions require that all reported
defects be tracked to resolution; however, resolution can include
deferral to a subsequent release or deciding that a particular defect
isn't worth fixing. We typically require that operational defects (ones
that would interfere with use of the product) must be fixed before ship,
but there is a review step that can allow exceptions, if the business
agrees.

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

That's fair.

---
| Pardon me, and no hard feelings.
---

That's OK, I overheat sometimes, too.

scott
--
scott preece
motorola urbana design center (il67), 1800 s. oak st., champaign, il 61820
e-mail: ***@urbana.css.mot.com fax: [phone]
phone: [phone] cell: 217-433-6114 pager: ***@msg.myvzw.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

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