Do you know where your variables are? PerlMonks

### Re: "Practices and Principles" to death

by zentara (Archbishop)
 on Feb 29, 2008 at 16:23 UTC ( #671205=note: print w/replies, xml ) Need Help??

in reply to "Practices and Principles" to death

Preventing 99% is hard. 99.9% is incredibly hard..... you have to stop somewhere.......decide where exactly to stop, you have to sit and think what the real cost of failure is

Think cost of insurance!

From my engineering school back in the 70's( things may be more precise now), 3 decimal places of accuracy was considered as good as you could get, because 4 decimal places involved estimating so many variables(especially temperature), that it would be fruitless to attempt.(also we were limited by sliderule accuracy :-) )

My point is that you only need to test to a level so that a court won't find you negligent if there was a failure. After all, money is what it is all about, being sued for negligence in a failure is what you need to avoid.

So it seems that in this day and age of insurance for everything, you would test to a level that makes the cost of insurance still acceptable. If testing to 99.99% saves you 100,000 on insurance, but requires an extra year of a team of programmers working, is it worth it?

I'm not really a human, but I play one on earth. Cogito ergo sum a bum
• Comment on Re: "Practices and Principles" to death

Replies are listed 'Best First'.
Re^2: "Practices and Principles" to death
by amarquis (Curate) on Feb 29, 2008 at 16:50 UTC

That's true (Especially for contract workers), but I think that the advice is more general. It doesn't matter what specifically the costs of failure are. They may be lost sales to unhappy customers, they may be bad reviews/press, or even insurance or being sued.

What matters is that you sit down before trying to create a system, you do good old fashioned cost/benefit analysis. What techniques get your team from point A to point B, and leave you with the most resources at the end of the day? Maybe automated Test::* based design is the way to go. Or, maybe the benefits of that method outweigh the cost of both training your team to implement and actually implementing it. You know your people best, and therefore you are the only one equipped to make that choice.

I think that BrowserUK and I disagree on the usefulness of Test::*. Maybe it is because he's a more experienced programmer than I and it just represents overhead for him. I don't know. I think we do, however, agree on the fact that you need to think about what you are doing and whether or not it makes sense to you, rather than burning a pig in a hut/cargo culting/whatever you want to call "pick whatever is popular and just do it."

I grew up in Detroit, and the big problem back then was "how much money do you put into highway safety". Did you know that with enough money, you can make a 99.99% safe highway? But would they spend it?....no... bad publicity be damned. What it ultimately came down to, was the cost of an human life. They could compute all the losses due to insurance companies paying out death and accident costs, and it was cheaper than making the highways safer. Same with the Pinto gas tank. Remember them exploding? But it was cheaper to payoff all the people sueing, rather than fix the problem.

So nowadays it comes down to what the value of a human life is, or for that matter, the value of a corporation. Nowadays, it's quite common for a corporation that gets huge bad publicity, to declare bankruptcy, and reform under another name.

Since this touched on Sattellites, and space, the issue is definitely on the table....... what is the value of an astronaut's life?

I'm not really a human, but I play one on earth. Cogito ergo sum a bum

An interesting question. I spent about 5 years as a Chief Systems Engineer at NASA in the early 80's...starting about 6 months before the second flight of the space shuttle...and ending when I transfered to Albuquerque, NM, with my wife (who had just finished medical school and was enter her residency) about a year after the Challenger disaster.

NASA was wrestling with that exact question: what is the cost of an astronaut's life. They concluded that if the Space Shuttle was to ever become the '18-wheeler of space' then they needed to get past the historic view of 'preserve astronaut life at all costs'...which had been the mantra of all of the Mercury, Gemini, and Apollo flights.

So they boldly concluded that it was inevitable that astronauts would be lost (I still remember, vividly, a big meeting where we told almost those exact words)...they argued that the public expected and needed (with respect to the possible loss of astronauts' lives) us to 'get past it.'

So they embarked on a course (which I wrestled with almost every day in my job) that we had to focus on 'minimal testing', 'production mentailitly', etc.

So we did...and costs began to go way down and we were turning Shuttle flights at an effective rate of about 10 per year (compared to the roughly 0.75 per year of the first few Shuttle flights).

And then came Challenger. The public pretty much crucified NASA...and, in my opinion, NASA has never recovered.

We all learned that the value of astronauts' lives was not at all related to any insurance computations or other 'typical' cost estimating strategies.

It looked to me like it was the cost of an entire many-billions-of-dollars Agency's reputation and ability to gather and consilate funds to continue their service to the taxpayers. I would argue that the cost of an astronaut's life is almost inconceivable.

ack Albuquerque, NM
…you can make a 99.99% safe highway?

You could make all roads 99.9% safe for free (well, for those cost of a little legislation). Institute a 25mph/40kph maximum speed limit. You just saved 40,000 lives in the US alone! And herein lies the real problem and what dragonchild is talking about. For those 40,000 lives you will pay uncountable billions, eventually trillions, in lost time, work hours, unused infrastructure, higher gasoline consumption, more pollution, fewer jobs, less agriculture, etc, etc. Everyone will suffer -- not just the unlucky, or the unseatbelted, drunk, or over-tired who got what they asked for -- quite a bit in this particular case, and it seems likely that more people would die in the long run from the staggering losses to mobility and the economy than would ever die in car wrecks.

I feel I must note that I'm not saying everyone should evaluate things like a business robot. If human safety is a factor in one's project, I certainly would hope that they'd be thinking beyond insurance and legal costs.

Re^2: "Practices and Principles" to death
by shmem (Chancellor) on Mar 01, 2008 at 13:43 UTC
There's more to failures than monetary costs - reputation loss, as ack wrote, and there's no insurance against that.

I'm not into space stuff whatsoever, but recently I've been working for a manufacturer of satellite equipment. They produce amongst other things power amplifiers for satellite emitters - those beasts that produce 400W worth of transmission energy.

They explained to me that whilst most if not all satellite components are redundant and connections can be routed inside the satellite to overcome an outage, their equipment must perform 100%. Not because of monetary failure costs - they have insurances anyways, I guess - but because of the reputation loss it would mean if a newspaper ran the line "Satellite outage due to power amplifier failure produced by company XY". They could look for other things to produce, then...

--shmem

```_(\$_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
/\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.(\$e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;\$e.e && print}```

Create A New User
Node Status?
node history
Node Type: note [id://671205]
help
Chatterbox?
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (11)
As of 2017-07-21 12:15 GMT
Sections?
Information?
Find Nodes?
Leftovers?
Voting Booth?
I came, I saw, I ...

Results (321 votes). Check out past polls.