Re: Apollo. The only thing I never understood

From: Jay Windley (webmaster_at_clavius.org)
Date: 08/25/04 

Date: Wed, 25 Aug 2004 14:56:55 -0600

"Derek Lyons" <fairwater@gmail.com> wrote in message
news:4135d785.5077765@supernews.seanet.com...
|
| What I'm objecting to is the isolation of one segment of
| the chain and then basing an argument on that and supposition.

Fine, but why object? If you choose to regard the problem a certain way,
that's your prerogative. But it does not have to be the only way of looking
at a problem. I'm saying, "Try looking at the problem like this." And
you're saying, "No, you have to look at it all together like this." Both
methods have merit, but I want to discuss *a* particular matter in
engineering philosophy that requires separating a chain of events into its
separate links.

My old professor -- who was an Apollo engineer -- kept saying things like,
"The seat belt doesn't care what the car hits or why." That's a profound
way of approaching engineering reliability. By engineering each particular
component or step to be as reliable as possible within its own limited
scope, you increase the overall reliability of the entire design, over and
above any global enhancements or constraints you might adopt. This was the
way Wernher von Braun worked. He didn't care what got you in that
particular situation; he was only concerned with how to get you out of it.

| Once cannot separate an accident from it's sequelae.

It's done all the time, *precisely* because, in a complex system, you cannot
reliably predict all the interactions. It's also precisely why von Braun's
engineering was always so much better than many of his peers. Instead of
trying to foresee every process path -- planned and unplanned -- he
decoupled the elements of his designs and treated each one as deserving of
additional margin. This made the overall design robust, even when
unexpected interactions occurred.

| As I said to Jay there is a world of difference between "A
| Challenger class accident is survivable in a properly designed craft"
| (which is what he meant), and "The Challenger accident was
| survivable", (which is what he said).

No, that's *not* what I said. I said (literally), "Booster failure was
considered non-survivable, even though CHALLENGER proved that was not true."
You seem to assume that by "booster failure" I meant the totality of
everything that went wrong with CHALLENGER's final flight. No -- I meant
"booster failure" in the literal sense: one link in a chain of events. And
you put your interpretation in quotes, as if to suggest it was what I said.
Please stop putting words in my mouth, and please stop trying to interpret
what I meant for other readers here.

I never claimed the CHALLENGER accident was survivable. You just
interpreted my statement that way. I'm not even claiming that a
CHALLENGER-type accident would have been survivable in a properly designed
vehicle. I'm saying that knowing what we know now, we might have approached
the design and operation of the shuttle differently. It might not have
changed the outcome, but it would have been thought about with a different
set of assumptions in place. That's the point that served the discussion in
which the statement appeared: that we make assumptions in designs that
suggest legitimate and necessary corner-cutting, and sometimes those
assumptions prove false. When they do, it's embarrassing.

I'd like to think we're violently agreeing, but you're making that hard. If
you would listen to what I said and am saying, instead of trying to tell me
what I said and am saying, it would help a lot. 

-- 
                                          |
The universe is not required to conform   |  Jay Windley
to the expectations of the ignorant.      |  webmaster @ clavius.org

Relevant Pages

  • Re: Exceeds maximum index number
    ... of optional "enforce relational integrity" property. ... > he was saying was that the relationships exist whether or not you use ... default join in the query design grid. ... > being prevented from implementing the definition of that database. ...
    (microsoft.public.access.tablesdbdesign)
  • Re: [PATCH RT RFC v4 1/8] add generalized priority-inheritance interface
    ... but priority end the only applies to tasks. ... the number of sinks per node. ... readers to num_online_cpus) which this design would retain. ... not how long the resulting chain can grow. ...
    (Linux-Kernel)
  • Re: [PATCH RT RFC v4 1/8] add generalized priority-inheritance interface
    ... the number of sinks per node. ... readers to num_online_cpus) which this design would retain. ... There is a finite lock depth defined. ... not how long the resulting chain can grow. ...
    (Linux-Kernel)
  • Re: Code Behind vs not
    ... There is a saying: give a programming task to 100 programmers ... >> chief reasons for separating an app into separate tiers, ... I use Dreamweaver to do my design and find it a bit of a hassle to ... If I add an object to my design page I need to go the codebehind page ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Hardware book like "Code Complete"?
    ... if we want to add scan chain ... -- Assign the clocked signals here per how the design needs it to ... advantage to their approach even though they recognize real costs to doing ... measuring productivity means using currency as your basis ...
    (comp.lang.vhdl)