4 ms·
it's even worse. on top of corrosion issues, they were certified for ranges to x to y degrees of temperature, that day the temperature was below minimum certifi
by LoSboccacc 12y ago
it's even worse. on top of corrosion issues, they were certified for ranges to x to y degrees of temperature, that day the temperature was below minimum certification range, so management reasoned that since it was outside test range, there were not enough data point to warrant a scrub.
- saalweachter 12y agoYou know, I don't think that management made such a call is rare or unique to NASA, and I don't think that such a call cost lives is even that rare. The problem is that the decision wasn't "push a button and kill a half dozen people", it was "launch and maybe have a problem or not launch and definitely waste X billion dollars and Y man-centuries of time". And we're terrible at those decisions. We - as individuals and organizations - are terrible at eating the sunk costs and paying definite to avoid maybe-catastrophes. Maybe sometimes it's rational but a lot of the time it isn't. And it's not just "management". All of us make these kinds of decisions when we ignore bugs to meet deadlines or push a feature that isn't really working just because we spent so much time on it.
- JamesSwift 12y agoI understand the point you are trying to make, but I disagree that 'all of us' make these kinds of decisions. The catastrophes the vast majority of us will run into are nothing compared to the catastrophes at play here.
- LoSboccacc 12y agoI add that these are companies where management is there to organize. when management takes over engineering, then it's over. see also http://www.amazon.it/Car-Guys-vs-Bean-Counters-ebook/dp/B004IYJEA6 http://www.amazon.it/Car-Guys-vs-Bean-Counters-ebook/dp/B004... and here for something more close to my experience and a partial counterpoint, see http://www.joelonsoftware.com/articles/DevelopmentAbstraction.html http://www.joelonsoftware.com/articles/DevelopmentAbstractio... it is most apparent in engineering focused companies.
- saalweachter 12y agoThe catastrophes involving space vehicles are certainly more impressive and public and obvious, but they aren't particular large in terms of loss-of-life. It's not hard to beat with a building fire or a large freeway accident, let alone a series of small failures or the really impressive failures like structure collapses or industrial-scale explosions. And while it's true that most of us aren't working on things which by themselves have the potential to cause these disasters by themselves, many of us are working on things that could spark an accident or cause one in progress to get worse. Any small electrical device could start a building fire. I've seen small USB devices, when left in a laptop in a bag, start smoldering. It was only luck that it was noticed before combusting. Nearly any component of an automobile could cause an accident -- the ignition switch, for instance. I don't remember if the floor mats were exonerated in the "stuck accelerator" cases (did it end up being driver error?). People use Maps applications and GPSs to find hospitals -- if you don't return the closest hospital or send people to a wrong address, people could die. Most of us don't work on Therac software that can directly shoot people to death, but it's not hard for your bug to be one of a chain of things that go wrong. Meanwhile, a lot of us work in or contribute to a culture which promotes risk-taking. Risk-takers get a lot of the done and only sometimes have problems, and get promotions, bonuses, congratulated, and trips to tropical locales. Sometimes things go wrong, but a lot of times you'll be forgiven because you perform so well. If you're overly cautious, things may never go wrong, but you also won't get as much done and you'll probably not get as much praise, and might even be let go for being low-performing. This may not directly result in any deaths, but it contributes to an industry-wide culture where risk-taking is the norm and success is defined as "getting a lot right" and not "getting very little wrong".