!Re: Nuke Redmond!

From: Richard Erlacher <edick_at_idcomm.com>
Date: Sun Apr 9 01:54:09 2000

The conventional wisdom where NASA is concerned, is that they HAD high
standards through the Apollo program and that shortly thereafter, a lot of
people left and apparently took vital talents with them. I've not worked
directly with NASA people in a very long time, and can't agree or disagree
with that view.

I did work on one critical NASA program back in '86-'87 and was impressed
with the cavalier attitude they displayed toward loss of human life vs. loss
of hardware. They had ground rules which defined conditions that we, on the
engine controller analysis team, determined would absolutely and in all
cases cause a catastrophic failure on the launchpad with loss of life and
loss of lots of hardware, costing way more than the $2e9 that the shuttle
cost back then. One of the guys ran the numbers and a simulation of the
effect of igniting all the LOX and H2 in one place, subsequently determining
that we hadn't the technology to build a comparably destructive nuclear
weapon, even the new high-efficiency types in the 40-50 TTon range.

That's all speculation, I guess, but I did find it appalling that NASA
considered in-flight power losses not detectable during ground testing were
simply normal operation, hence required no special action, even though the
defect could be inherited from one mission to the next. I don't know where
this is supposed to lead.

Anyway, I don't see NASA as a promising place to work for now.

Dick
----- Original Message -----
From: Sean 'Captain Napalm' Conner <spc_at_armigeron.com>
To: <classiccmp_at_classiccmp.org>
Sent: Saturday, April 08, 2000 10:23 PM
Subject: Re: !Re: Nuke Redmond!


> It was thus said that the Great Richard Erlacher once stated:
> >
> > > I even talked to the original programmer and his attitude was
basically
> > > ``Hey, the customer paid for it and it works. I'm not working on it
again.
> > > Screw you dude!'' It's rare when I want someone else shot on sight,
but he
> > > was one of them.
> >
> > The notion that the original programmer will live forever, hence, always
be
> > available to fix things, is one of the main weaknesses of programming
> > philosophy. Even I have fallen into that one. That's why plgramming
> > languages have a construct for comments.
>
> It's not that the programmer will live forever, but that a programmer
> doesn't have to live with his mess that upsets me more. Once the code
> becomes a quagmire he can leave it behind and move on, much like the
fellow
> whose code I had to maintain (or the sysadmin whose network I inherited.
I
> swear I wanted to drag him back (behind my car) to the office and force
him
> to fix his poor excuse for a network but I digress ... )
>
> Then there was a job I held for two weeks at a software company. Their
> coding standards mandated NO COMMENTS! Their rational---comments are
often
> misleading and don't match the code. So the code IS the COMMENT, as
that's
> what the computer is executing (and I won't go into their other insipid
> coding standards). I left over major disagreements over coding standards.
>
> [ some slight shuffling of paragraphs here ]
>
> > Well, heuristic progamming is the hallmark of the American school of
> > programming. The Japanese have, in recent years actually applied
genuine
> > and therefore 30+ (probably much older) year-old engineering principles
to
> > software engineering, a term which, in the American school, is still an
> > oxymoron, and have regularly been reported to be bringing software tasks
in
> > within both budget and schedule.
>
> > > [2] In C with random indentation, C++ style comments (which his C
> > > compiler accepted) and race conditions that would cause it to
> > > fail under certain circumstances.
> >
> > Well, that's not as bad as finding potential catastrophic failures and
> > dispensing with then by changing the ground rules. That's how NASA
likes to
> > do it.
>
> I'm not entirely sure what's happened with NASA recently, but during the
> 90s I read that the software development group for the Shuttle had the
> highest quality assurance program period, and that up to January 1986,
there
> had been only two bugs that made their way to the shuttle simulator (which
> is considered earth shattering bad among the programmers). Since 1986 I'm
> not sure if it has declined, but I did read an article within the last
year
> that upheld the fine tradition of NASA programmers with being on time and
> within budget, all while working 40 hour weeks (which is something not
even
> heard of in the industry).
>
> It might be NASA management doing the fiddling, but I doubt it's the
NASA
> programmers. I wish more was written on the NASA programming teams.
>
> -spc (Or marketing hit with large clue sticks)
>
Received on Sun Apr 09 2000 - 01:54:09 BST