The result would be a catastrophe (1985)
lettersofnote.com
lettersofnote.com
When I saw this, I realized we would have to start over and choose different components able to tolerate the higher voltages. My managers disagreed, arguing that if we caused problems, we would be denied a follow-on contract for similar inverters to be deployed in the payload bay. The managers composed a reply to NASA in which there was no problem, things were fine, let's forge ahead.
I was a mere engineer, I had no management authority, and I hadn't been consulted about the reply. When I heard about it, I sat down and wrote a letter of resignation and pushed my letter into more hands than was absolutely necessary. I made some comparisons that at the time might have seemed over the top (like the Apollo file that killed three astronauts, a disaster resulting from lax oversight).
In my case, because of my having distributed the letter farther than was absolutely necessary, my managers were forced to reverse themselves, I was able to redesign my inverters in a safe way, and we got the follow-on contract in spite of not being seen as "team players".
Many years later, at the time of the Challenger disaster, it finally dawned on me that, had I disregarded the overvoltage issue as my managers had wanted me to, and if something had gone wrong, I would have been held personally responsible, because I was the only person with the level of technical knowledge required to make the call, and my managers could disavow any responsibility. At the time, I made the right decision, but for reasons that I hadn't fully thought out -- if my equipment had failed in-flight, I would have been held responsible, and that would have been a perfectly just outcome.
Just today, I pointed out that a backend web service system for an important (HR) function was so insecure that simply putting a single quote in an end-user input field would crash it, and that a SQL injection would be trivial. After a little arguing from them ("You don't know what a SQL injection is") they changed their tune to "Just put a limit on the frontend", and when I told them that could be trivially bypassed, they said "No one will ever think to try that." When I pressed further, they continued to "It's an internal app, no one would attack it" then to "And do you want me to put locks on all the doors and cabinets around the office too?"
So that's a case where there's some reasonable level of understanding and just a refusal to act.
I also recall a time (at a different company) when I discovered a public read/write anonymous FTP server setup externally facing with no firewall rules. When I pointed out the problem, they said, "that's what our customers are used to, we're not going to change it." and when I pushed, "No one will ever find it anyways." Literally less than a month later that server was overrun with illicit content.
It happens. Unfortunately, as we've seen with the Volkswagen debacle as well, it happens even when regulation or (in the Challenger case) human life is on the line.
[1] https://www.youtube.com/watch?v=cdOGPBnfoKE
[2] http://www.amazon.com/Cadillac-Desert-American-Disappearing-...
You're also overestimating the business impact of a security breach. This is an area where people's moral compass overrides their shrewdness. Notice that Anthem is still in business despite the worst possible breach, for example.
It's worth trying to improve security, if possible. But it takes one of two things: (a) leverage, or (b) patience. One of the main reasons that companies get a security audit is because a different company forces them to. They get an audit in order to obtain a CFD (client facing document) saying that they are secure. Without this, the other company will not do business with them, which is the sole reason why the security audit happens.
The other way -- patiently pointing out ways of improving the situation, and explaining the business merits of allocating time to this pursuit -- does not usually result in meaningful security improvements. This is an unfortunate fact of the industry, partly because security breaches do not usually put a company out of business. There are exceptions to this, but that is the common case.
Realistically, to be safe, you'd have to gut the whole thing and replace it. You can be a "little safe" by doing something silly like replacing ' with '' but that doesn't protect in non-string cases, etc, and I wouldn't propose a solution like that because it could give a false sense of security.
I understand the push-back. The backend is maintained by others and it would add to their workload to secure it. That's a real and actual cost.
As for the business impact, you are right. I just wanted it to be "on the table" that I informed people of the situation, so that if there is an exploit in the future, I don't get the "why didn't you tell anyone this was vulnerable?" or something like that.
The solution is to run every input through a function that replaces each single quote with two single quotes. That is all that's required to prevent SQL injection, since it's not possible to construct a valid query regardless of the injection point. (EDIT: This refers to string inputs. Numeric inputs are handled in the obvious way, as is ASC/DESC. Injection into an ORDER BY clause is not usually exploitable. These are all of the cases.)
If you propose this solution to management, they may be somewhat more likely to take action, since it can be applied to the existing system.
but inputValue is a string (from untyped xml), but is put into SQL without quotes because SomeNumber is an int type in the database. Since the xml is constructed without validation, an attacker could put any value there, including strings to inject, and do so without using quotes.
Management is more likely to listen to this, since it doesn't require a rewrite.
So you are implying that every warning issued management ends up resulting in a failure of medium, large or catastrophic proportions?
There is no data available almost certainly on warnings issued where nothing has happened.
I then cited two anecdotes where warnings had been given. In one case, a breach followed, in the other, so far it has not. I would assume most warnings that are ignored turn out to be non-issues.
Every place I've worked have had that. I would have answered yes.
This could have a huge chilling effect.
And yeah that has cost me.
China became frozen in amber, so to speak.
I refused the assignment. When they didn't fire me on the spot I followed the managers who made the request and when they would ask another engineer to do it, I would warn the engineer that they could be held personally responsible for any injuries or fatalities that could occur.
I fully expected to be fired but surprisingly, management just gave up on the idea. Perhaps my insistence that it was a bad idea convinced them.
>Viewing history through the lens of hindsight, we vastly underestimate the cost of effective safety precautions. In 1986, the Challenger exploded for reasons traced to an O-ring losing flexibility at low temperature. There were warning signs of a problem with the O-rings. But preventing the Challenger disaster would have required, not attending to the problem with the O-rings, but attending to every warning sign which seemed as severe as the O-ring problem, without benefit of hindsight. It could have been done, but it would have required a general policy much more expensive than just fixing the O-Rings.
>Shortly after September 11th 2001, I thought to myself, and now someone will turn up minor intelligence warnings of something-or-other, and then the hindsight will begin. Yes, I'm sure they had some minor warnings of an al Qaeda plot, but they probably also had minor warnings of mafia activity, nuclear material for sale, and an invasion from Mars.
>Because we don't see the cost of a general policy, we learn overly specific lessons. After September 11th, the FAA prohibited box-cutters on airplanes—as if the problem had been the failure to take this particular "obvious" precaution. We don't learn the general lesson: the cost of effective caution is very high because you must attend to problems that are not as obvious now as past problems seem in hindsight.
Without that alternate case, languorous management is the most likely culprit.
"The best way to predict the future is to invent it."
When the current Commander in Chief of the United States of America, the most powerful military in the world, says "the biggest security problem [is] Osama bin Laden," that's something entirely different.
And frankly, I trust the opinion of Richard Clarke more than I trust yours OR MINE.
Yes, it took 10 years to find someone the Commander in Chief was not that concerned about.
To believe otherwise is to believe, essentially, in predetermination. Hindsight bias does not imply that things would have turned out the same today, no matter what people did in the past.
Surely you can't make this argument without detailing that?
Your quote claims that it would have been much more expensive to address all of these things, but what's the support for that statement?
My (extremely limited, to be sure) understanding is that there wasn't anything else that severe. The O-ring problem was dire, and the only reason it didn't get attention was because schedule pressure and go-fever caused management to minimize the problem.
Note that the warning signs mentioned in the quote were not just theoretical test results, but also several cases where fire was getting where it was not supposed to be during actual flights. Further, there was strong evidence that these incidents were linked to cold weather. "Don't fly when it's really cold" wouldn't have been a particularly expensive mitigation, either, even if you argue that suspending flights until the problem was investigated and fixed was not reasonable. I mean, you're launching from Florida, a restriction not to launch in temperatures under 50F wouldn't have been a terrible burden.
How many other warning sings were as severe as the O-rings and as easy to mitigate? My money is on "zero" in which case this argument is just so much noise.
That's my understanding as well. Boisjoly wrote a detailed essay describing the thought process that they went through to arrive at their conclusion that the O-rings were a critical problem (the other three authors are a professor and two students at RIT):
https://people.rit.edu/wlrgsh/FINRobison.pdf
The essay is a response to a criticism by Edward Tufte that the engineers did not present the issue properly during the telcon the night before the launch, and that this was the reason that NASA did not agree to scrub the launch. It makes clear that, at least in the minds of the engineers, there was no other issue even close to being this critical. Granted, they were concerned with only one subsystem, the SRBs--but the fact that this issue also dominated the telcon the night before the launch indicates that there was no other issue even close to being that critical in any other subsystem either.
[Edit: It's interesting, btw, that in the essay linked to above, Boisjoly accuses Tufte of precisely the thing Yudkowsky is talking about in his article: hindsight bias. He argues that Tufte did not recognize or allow for the fact that the engineers at the time had limited information, but talks as though they knew everything that was known in hindsight.]
The premise of "failing to convince management" relies on the notion that "management can do no wrong". For example, if you tell your boss that we're about to drive the bus off a cliff, and he doesn't listen, it's your fault.
This is the way things work in many organizations, it's an old-school approach to management, but to me it is purely dysfunctional. When someone tells me I'm about to drive off a cliff, I say, "Wow, thanks! What did I fail to see that got us into this mess in the first place?"
Aside from Tufte's notion of blame, I think his essay is very instructive.
I completely agree, and AFAIK the Tufte essay does not even mention a critical point in this regard, which the Boisjoly paper does. The engineers had already tried to get all flights stopped until the O ring issue could be investigated and properly understood, in the August before the Challenger flight. NASA had refused. So the NASA managers were already aware that there was a critical flight risk, and they had already chosen to ignore it. That means it definitely wasn't a case of bringing new information to management's attention in order to drive a decision. It was a case of trying to get them to change, at least in part, a decision they had already made.
The argument about cold temperatures has to be viewed in that light--it was an attempt to find something, in the absence of good, hard data and a solid understanding of what was going on, that would at least get NASA to delay some flights, since they had already refused to delay all flights. In fact, considered solely on engineering grounds, the argument about cold temperatures was fairly weak (as Boisjoly points out in his essay). But it was weak not because cold temperature flights were almost as safe as warm temperature flights; it was weak because warm temperature flights were almost as unsafe as cold temperature flights! (A previous flight with significant blow-by had been made at a temperature of 75 F, and test stand data showed that the O-rings were not sealing completely at any temperature below 100 F.) But the engineers couldn't say that the night before the Challenger flew, because they had already said it back in August and had been ignored.
I don't think that one detail is the only serious flaw in the essay. As far as I can tell, Boisjoly's criticisms--that Tufte misunderstood the actual issue (it was blow-by, not erosion), and that he misunderstood what information the engineers did and did not have (for example, they didn't have reliable temperature data for many flights)--are valid.
The SRBs were not designed to work below 40F, so it would have been very reasonable to postpone launch (yet again). However, Reagan was going to give his State of the Union speech on that same evening, and putting a teacher in space was supposed to be a highlight of the speech...
It's very readable and goes into a bunch of other issues at NASA at the time beyond the O-ring failure, which Feynman treats as a symptom of more general engineering and cultural problems.
> Then he says, “I was working on my carburetor this morning, and I was thinking: the shuttle took off when the temperature was 28 or 29 degrees. The coldest temperature previous to that was 53 degrees. You’re a professor; what, sir, is the effect of cold on the O-rings?” “Oh!” I said. “It makes them stiff. Yes, of course!” That’s all he had to tell me. It was a clue for which I got a lot of credit later, but it was his observation. A professor of theoretical physics always has to be told what to look for. He just uses his knowledge to explain the observations of the experimenters!
However, Feynman admits at the end of his multi-chapter account of serving on the commission that Kutyna had coyly played Feynman:
> Another thing I understand better now has to do with where the idea came from that cold affects the O-rings. It was General Kutyna who called me up and said, “I was working on my carburetor, and I was thinking: what is the effect of cold on the O-rings?” Well, it turns out that one of NASA’s own astronauts told him there was information, somewhere in the works of NASA, that the O-rings had no resilience whatever at low temperatures—and NASA wasn’t saying anything about it. But General Kutyna had the career of that astronaut to worry about, so the real question the General was thinking about while he was working on his carburetor was, “How can I get this information out without jeopardizing my astronaut friend?” His solution was to get the professor excited about it, and his plan worked perfectly.
If we take Feynman at his word, to me this is a great description of how science and bureaucracy and invention (and, sometimes, disaster) works: it's not always just random eurekas, or study-real-hard-and-you'll-figure-it-out...sometimes the information is already well-known, and obvious, but for various logistical/political/bureaucratic reasons, it isn't immediately disseminated or explored.
via: Feynman, Richard P. (2011-02-14). "What Do You Care What Other People Think?": Further Adventures of a Curious Character (Kindle Locations 2923-2930). W. W. Norton & Company. Kindle Edition.
"Kutyna: On STS-51C, which flew a year before, it was 53 degrees [at launch, then the coldest temperature recorded during a shuttle launch] and they completely burned through the first O-ring and charred the second one. One day [early in the investigation] Sally Ride and I were walking together. She was on my right side and was looking straight ahead. She opened up her notebook and with her left hand, still looking straight ahead, gave me a piece of paper. Didn't say a single word. I look at the piece of paper. It's a NASA document. It's got two columns on it. The first column is temperature, the second column is resiliency of O-rings as a function of temperature. It shows that they get stiff when it gets cold. Sally and I were really good buddies. She figured she could trust me to give me that piece of paper and not implicate her or the people at NASA who gave it to her, because they could all get fired."
(although the oral history above suggests that she was concerned for other people's careers, not her own, but it's still kind of amazing)
— Personal observations on the reliability of the Shuttle (Rogers Commission Appendix F) by R.P. Feynman
Actual statistics from the life of the shuttle, last flown as STS-135 8 - 21 July, 2011:
Total launches 135
Failures 2
Successes 133
Failure rate: 1.5%
If so, the risk for the entire system (shuttle) should be higher, not lower.
Edit: To be clear, I wasn't saying it was lower.
Sorry, I didn't mean to refer to you; I should have been more clear. I was referring to NASA's or anyone's estimates for the shuttle.
I am genuinely curious why the warning was ignored. I am hesistant to believe it was through malice or sheer incompetence. Does upper managment get two overblown warnings per week by engineering, so that this critical warning was "drowned by the noise"? Or were there good (at the time!) reasons to focus on other issues first?
And it may be that the flaw is this uni-dimensional hierarchy that we seem to like, that seem efficient most of the time, but in reality not only miss edge cases but can cause them. The managers simply did not always 100% trust the engineers. Ultimately, the people with the power over go/no-go were more managerial than engineers, were more concerned with the politics, cost, perception of delay than they were at risk assessment.
All spending of money in any company or government is basically the same: someone at the top delegates the vast majority to someone else. And they choose that someone else based on trust. And the longer than chain is, the greater the likelihood someone is put in position where the chain of trust is just flawed. And you hope it gets exposed where people don't die, obviously. But that didn't happen here.
And that's why a bunch of people got angry at Feynman as well as Boisjoly. They exposed that the wrong people were making key decisions. Had they been the right people, then loss of life wouldn't have happened. Anyone that wrong is going to be angry, it's a personality flip of the coin whether they get angry with themselves for their mistake or with others for exposing it.
That's just perfect
I never heard that before. Is there a source?
However this may not be true. While trying to find an e-source, I read that there were some politically-motivated rumors that the white house ordered the shuttle to launch for this reason. Feynman investigated that rumor and didn't find any evidence that the white house ordered the launch.
It's possible the detail about an on-air tv conversation between the president and a schoolteacher astronaut could have been fabricated as well to make Reagan look bad, or it could have been based on elements of truth. For example she was expected to broadcast 2 lessons to students from space, so the capability definitely existed. It doesn't seem too far out that they would have liked for this conversation to happen during the State of the Union, though that doesn't mean the white house ordered the launch.
I read this in Edward Tufte's essay Visual and Statistical Thinking (http://www.edwardtufte.com/tufte/books_textb), which discusses how better information displays might have convinced NASA management to postpone the launch. It also appears as a chapter in his book Visual Explanations.
I didn't have any luck finding sources on the internet (lots of keyword overlap). Tufte is much better informed than pretty much all of us, though it's possible he printed what amounts to an unsubstantiated rumor. FWIW he also served on the Columbia accident investigation board.
I think there were other pressures to launch as well. The launch date had been postponed 3 times already for various reasons. Cynical danek: I wouldn't be too surprised if some manager's performance review was based on how many launches took place on the scheduled date.
On a tangential note, I've always wondered about this sort of idiom. 20/20 vision is the equivalent of a 100 IQ -- it is equivalent to that of a "typical human". Perfect vision would be 20/ε (you can see at 20 feet what an ordinary human could only see from an infinitesimal distance), and mundane glasses will often correct vision past 20/20.
It seems like such a low bar for hindsight to meet.
I find this phenomenon so difficult to understand.
But one guy tells the world exactly how you screwed up. Now you're in fear of your reputation and job -- but if he'd just kept his mouth shut, then you might be okay.
It’s sad, but the natural tendency of organizations is to close ranks in situations like this. It is incredibly tough to perform an open, honest, self-assessment. The procedures need to be in place to force the self-examination and strong leaders need to push for it. Even then, politics sometimes place the blame on the wrong people. I’ve seen this happen time and time again in the military from working with SF in Iraq [1] to joining a squadron just after a disaster [2].
[1] http://www.nytimes.com/2008/08/20/world/africa/20iht-20iraq....
[2] https://en.wikipedia.org/wiki/2008_San_Diego_F/A-18_crash
In particular his material on bureaucracies is relevant: when threatened, bureaucracies immediately fight for self-preservation. Boisjoly was threatening the bureaucracy and so had to be eliminated for it to survive. Its actions makes perfect sense in the light of this. Ugly, yes but understandable.
Since "everyone else" > "you", majority rules, you go.
It's a bureaucracy problem. I've seen it, and it's also gotten me at least once, when I decided to stick up for principles. My ego left intact, my job did not.
This is also why getting fired should not automatically carry a negative stigma.
I have a counterpoint- I bet that, given any risky endeavour, there are ALWAYS some naysayers/doubters. So the probability that someone at an organization ends up being correct when a disaster occurs, is probably fairly high. Thus, just because you won the disaster prediction lottery, may not entitle you to as much acclaim as you might think.
Conversely, achieving success despite taking a great number of risks in the process, may not entitle you to the acclaim that you do get.
http://williamwolff.org/wp-content/uploads/2013/01/tufte-cha...
http://www.onlineethics.org/CMS/profpractice/exempindex/RB-i...
Tufte's pictures of the (superfluous) rocket graphics showing the temperature vs. his redrawing, placing temperature on the x-axis are very convincing.
1) Tufte had temperature datapoints for the previous launches that the Boisjoly's team didn't know[1]. I assume "know" to mean the complete historical data wasn't all consolidated conveniently at his fingertips before the disaster. Presumably, Boisjoly's team could have gotten it if it had occurred to them to gather it. Essentially, Tufte had the benefit of "hindsight" to make his compelling diagram showing cause & effect.
2) GIGO garbage in is garbage out. The Tufte temperature datapoint assumes that the outside ambient temperature is equal to the O-ring temperature[2] so substituting one for the other is wrong. (E.g. It's wrong to put them both on the same X-axis.)
Quotes excerpted from http://www.onlineethics.org/CMS/profpractice/exempindex/RB-i...:
[1]"He thus supposes that they knew the temperatures at launch of all the shuttles and, assuming they acted voluntarily, infers they were incompetent."
[2]", in addition, mixes O-ring temperatures and ambient air temperature as though the two were the same."
For (1), you're correct that the engineers did not have the historical data. More than that, though, it did occur to them to request the data, but they were stifled by Morton Thiokol Management (and NASA).
To start with, there were a variety of previous problems with the O-rings caused by variables that appear unrelated to temperature. These problems were resolved, but prevented anyone from seeing a pattern. It was only on the basis of the single data point in SRM 15 that Boisjoly requested temperature data in advance of the launch.
Obtaining such data was far from simple, because, as you mention, the temperature of the O-ring isn't the same as the ambient air temperature. Thus, obtaining the data was relatively involved and required knowing many variables: time on the pad, the gradient of ambient temperature, the temperature at which testing was conducted, and so forth. For this reason, the engineers didn't compile the data themselves (unclear what process they'd need to get the data).
The engineers thus requested the data in advance, but had not received it. They had precise data on only two data points (at 53 degrees and 75 degrees), so the rest of the data in the chart was compiled after the fact.
"The data necessary for a calculation of O-ring temperatures was thus not collected all along during the shuttle history. And when Boisjoly asked for that data in September, along with much other data, any one of which might have been the crucial missing piece to explain the anomalous cause, it was not supplied. In fact, the engineers received none of the data they requested."
* Both axes of the chart are inaccurate. The temperature on the X axis intermingles ambient and O-ring temperature, but they're not the same (imagine ocean temperature vs air temperature). The vertical axis, O-ring damage, is semi-relevant, but the important question is whether the O-rings held a seal (degree of blow-by). O-ring damage probably correlates, but seems like a proxy that may be misleading.
* The data available in the chart was not available to the engineers at the time. There was only one previous failure (SRM 15) that led anyone to believe temperature itself was an issue. They had two valid temperature data points (SRM 15 and SRM 22), and correctly pointed out that another launch at 29 degrees was completely outside their tested range and would be inherently risky. It's not clear to me that a scatterplot with two datapoints would be that effective.
Furthermore Boisjoly criticizes that Tufte presumed to judge the engineers, for the following reasons:
* The engineers previously recommended no launch should occur, months in advance (due to previous O-ring issues), but NASA overruled them.
* The engineers recommended, and their managers accepted, that the low launch temperature was outside their test database. NASA came back and requested proof that the temperature was dangerous, but the engineers could not comply, because the parameters were extreme enough that they had not tested them. They couldn't prove a negative. The managers at Morton Thiokol and NASA then jointly overruled the engineers.
* The idea of putting together a chart was not something the engineers considered, because there were a variety of previous unrelated problems in O-rings (each resolved afterwards) that muddied that data, and muddies the data that Tufte presents.
* Tufte himself failed to research or note the pivotal information, and thus misrepresented the situation the engineers were in, and the data available, while imputing that the engineers should be held morally responsible for not presenting data they didn't have (and then going on to present such data himself, compiled after the fact and at his own leisure, incorrectly).
I spent my time as a kid living on Vandenberg Air Force base, and my father would drag me out to Minute Men missile launches early in the mornings. I saw several launches. Even two launched at once.
I had seen many launches before, so I had no expectation that they could go wrong.
Watching the shuttle explode like that was shocking.
This mindset is interesting. Issues like plane and train crashes grab headlines and are typically catastrophic, but end up being far more rare than, say, a fatal car crash. Similarly, the Space Shuttle had two major incidents in 30 years, and the Concord had only one, but they were very public and very catastrophic.
Is it the rarity or severity that make them such big news?
It helps just in terms of grabbing your attention, too. "Man drives into lake" doesn't make the news. "Man drives Bugatti Veyron into lake" does, just because the unusual car makes it more interesting.
In the case of Concorde and the Shuttle, the machines in question were not only rare, but beloved by many, and seen as a national symbol. It's almost like assassinating the country's leader.
It doesn't seem that long ago really. The weird thing is.. in that same amount of time in the future I'm going to be a 75 year old man:)
go for throttle up
and whenever the news shows that Y trail plume it still makes me ill to this day
Actually, more realistically:
"Brinton, do you know what this Boisjoly guy is talking about?"
"No Lund, I don't - his attitude is disappointing, we need team players."
"Thanks Brinton - I'll bring it up with his manager for his next performance review."
There is way more depth to this situation than the simple hand waiving 'everyone that supervises me is stupid'.
In reality, it's a very big problem for companies to disappoint their large customers (as NASA certainly was for Morton-Thiokol at the time), and I suspect that the engineers would have been quite annoyed at management if the ultimate result of a launch no-go was fewer contracts, lower pay and/or job losses.
This isn't to say that management did the right thing, of course, just that "lol management just throws some buzzwords around and never attempts to understand the problem" is basically the same attitude that caused this disaster - just seen from an engineering viewpoint.
Social pressure can influence people into engaging in wishful thinking. They made a horrible judgment call, and we should remember that that tragedy was authored by them. But if you think you NEVER would have fallen for it... you're not being self aware. There's a pretty decent chance you would have.
[0]http://freakonomics.com/2015/05/20/failure-is-your-friend-a-...
For me the "ah hah" moment was when it hit me that "Where were you when you heard about Challenger?" was my generation's version of, "Where were you when JFK was assassinated?"
Another easily observed one is music. Very few people are aware of much that happened in popular music after they hit 25.
You can listen through 65 years of pop music made so far. Then, if you live 80 years, you only lose about 45,8% of all pop-music you could have heard during your lifetime. That's not half bad.
If you include some blues, jazz and classical, that percentage goes down significantly.
Regards, 29 year old with 4 year long amnesia about music.
The most important sentence in the letter ("The result would be a catastrophe of the highest order - loss of human life.") is at the end of the third paragraph, and is effectively hidden by two paragraphs of dense, technical jargon that I, as a layman, cannot understand at all.
I honestly think that if he had just taken that sentence and moved it to the end of the first paragraph, 7 astronauts' lives could have been saved.
This document is written as a credible engineering analysis of a distinct problem and uses extremely strong terms. It isn't addressed to the general public, or an article on Buzzfeed, it is an interdepartmental memo from an engineer signed by his manager to the Vice President of Engineering.
Your example of "clear writing" would have just made this engineer look hyperbolic and likely undermined the issue even more. In a document like this, stating the physical problem up front is clear writing, and then, once the engineering problem is stated, he immediately states the possible outcome and then describes what he says as the management failure to allocate the appropriate resources, and how to fix it.
How it comes off to you as a layman doesn't dictate whether or not this is good writing. He wasn't writing it to you.
To help the busy reader, the first paragraph of a memo should summarize the whole document. (Like the abstract of a technical paper.) This document is about an engineering problem and it's serious consequences, so they should both be mentioned in the first paragraph.
And I think it's pretty disrespectful to the engineer who is still haunted by this to say that what he really should have done was switch some sentences around and that would have totally solved the problem.
This is a strongly worded document.
Making safety a priority doesn't mean starting every engineering document with the words "loss of life" which is a really common outcome of engineering failures on programs like this. Making safety a priority means putting the risk of an engineering failure up front and knowing that an engineering failure in a life-critical system is critical. Making safety a priority means people don't have to tell you what the stakes are every single sentence, because everyone already knows and so what you really communicate is how much risk there is, not the fact that risk exists. Making safety a priority means even if you're working on an engineering problem that wouldn't lead to loss of life, you fix the thing because you might be wrong and it might be part of a correlated failure one day that does lead to loss of life. Making safety a priority doesn't involve writing engineering documents in a way that makes them more amenable to skimming.
It's a rocket. Engineering doesn't have to go that far wrong on rockets for people to die. When someone sends a letter to a VP of engineering which begins with "This letter is written to insure that management is fully aware of the seriousness" then everyone who receives that memo is paying attention and if they aren't then it's not the writing skills of the people involved that are at fault.
I don't think a single person who was aware of the O-ring issue was unaware of the stakes. That didn't show up in any reports on the panel. What did show up was they estimated the risk of the problem wrong. The first sentence of this engineer's letter went towards establishing the seriousness of the engineering failure. Because that was the part that needed to be communicated most clearly.
Cut out the fluff like 'this letter is written' and 'a jump ball as to the success or failure.'
Rewrite the second paragraph with some verbs and a proper subject.
Not that any of this really matters in the end. The final decision was fully in the hands of management and NASA during a teleconference, during which argument was made.
Elsewhere in the discussion[1], we learn that key information about the O-rings had to be carefully, anonymously disclosed to protect the jobs of several people, including a prominent astronaut.
How do we avoid corruption when loyalty uber alles is the rule of almost all organizations?
For this NASA o-ring bullshit, simplest solution seems to be having the technical managers and the astronauts in the same in-group. Now your loyalty is about not getting your mates killed.
If you need a big organization, the trick is to have that internal network of squads and companies to work somehow non-corrupt and nice manner. This is where it gets hairy. Basically you can go with assumption of corruption and apply "transparency" or monetary incentives (sub contractors). Or you can assume that corruption does not happen. Sometimes the mere assumption that corruption does not happen stifles it. Practically for big companies failing less than your competitors is adequate for success.
> For small enough organization that "loyalty uber alles" prevents corruption.
How? There are many, many cases of people covering up for their fellow squad members.
> Or you can assume that corruption does not happen. Sometimes the mere assumption that corruption does not happen stifles it.
Hmmm ... that seems like a well-known recipe for encouraging corruption. How would that approach stifle it?
It's unlikely that one would be corrupt against ones squad members. So as squad member, you only have to worry about corruption of outside shit. People who affect you and are not member of same in-group are the problem from any individuals point of view.
>How would that approach stifle it?
Most people are good by nature. The only instance I've stolen from work was a situation where it was expected that I might steal from work. So I kind of showed to them that I'm more cunning than they are careful. A challenge. Another point comes from self image, if everybody sees you as corrupt asshole, you see yourself as corrupt asshole. So you might as well act on it.
In general people have strong tendency to act as is expected of them. Stronger than the tendency to act as they are told.
In my mind, what made this tragedy even worse was the way the program itself was conducted. You learn new modes of transportation and hardware by using it, many times to the point of exhaustion. We should have built a dozen orbiters and flown the shit out of them through hell or high water, learning as we went along. Instead we built 5 and every time something happened we backed farther away from the entire manned space program.
A lot of time was wasted, and the lessons we didn't learn? Somebody else is still going to have to learn them someday.
Edit: Grammar
Are you having serious engineering-related discussions with your management where they can't read 150 words before getting to the hook? (serious question, not snark)
Is everyone communicating via twitter or something? (sorry, that was a bit of snark)
I work in a related field, and am vaguely familiar with both the general makeup of this type of rocket and this accident in general. I also tend to write longer, more complex sentences.
I did not find it to be particularly 'thick', and I'm curious whether it's because I'm more familiar with the technical details and so avoided the glossy-eyed stare from that aspect or from the fact that a few dozen words in a sentence doesn't faze me.
The former would mean this shouldn't bother anyone practiced in the arts of spaceflight (such as the VP of engineering), but the latter would have been a problem.
Edit: stupid homophones.
"we stand in jeopardy of losing a flight along with all the launch pad facilities" should be in the first sentence of the whole letter, not the final one.
For example the author takes this sentence:
Pelicans may also be vulnerable to direct oiling, but the lack of mortality data despite numerous spills in areas frequented by the species suggests that it practices avoidance.
... and turns it into this:
Pelicans seem to avoid oil spills by avoiding the oil.
[1] "Revising Prose", Richard Lanham. http://www.amazon.com/gp/product/0321441699/ref=pd_lpo_sbs_d...
It's easy to trim sentences when you take away data.
Before: Perception is the process of extracting information from stimulation emanating from objects, places, and events in the world around us.
After: Perception extracts information from the outside world.
Yes, the first is more specific and more detailed, but the "outside world" includes things like objects and places and doesn't add much to the gist. The second one is certainly more readable.
I often see writing (especally from engineers) that is meant to be informative that is overwhelmed with irrelevant information. That is difficult to parse. Sometimes you want to pick out just a few relevant facts and leave out anything that isn't strictly needed so your audience understands the point.
It depends on your audience and you reason for writing what sort of information is needed and what is not needed. Its not an easy skill.
Ya it's a bad situation.
An ultra-executive summary is what your memo/email subject and first line should be. Then expand out with more and more detail as necessary.
The total loss of a future shuttle mission and the death of its crew is a near certainty with our current booster o-ring design.
Then I would omit everything else in the original letter except the request for staffing.
Let's hope the management reading the letter wasn't so fickle. Oh wait, hmmmmmm.
> The total loss of a future shuttle mission and the death of its crew is a near certainty with our current booster o-ring design.
From the point of view of the engineer, that would be a misrepresentation of the facts. An exaggeration.
You're basically outlining the difference between engineers and marketers. I don't mean that as a sleight - perhaps the situation called for a bit of "marketing".
In most organizations I've worked in (generally large ones), the rank-and-file engineers/scientists are below-average communicators (a stereotype, I know, but it's been true). They choose the wrong level of technical detail for their audience (or send it to such a large cross-section of people that there is no appropriate level for everyone). They certainly make grammatical mistakes. It's up to engineering management (who are generally better communicators) to pull the salient bits out of the communication and then pass that up the chain in a more clear manner. I certainly can't imagine a manager going "well, Darren's letter that warned me of a likely loss of human life used 'insure' instead of 'ensure', so I'm just going to assume that the rest of it is drivel and go on about my day".
Your way would certainly have been better. Related note, one of the best writing classes I ever took with regard to its effect on my current work was actually a journalism class. The notion not to bury the lede has been key as attention spans wane (apparently more than I'd realized).
- But how would you call it? Memo? If yes, isn't it a memo about an technical problem? Or an another way to ask: How to describe a technical problem without using tech jargon?
When I read it, it seems like a banal procedural artifact. No urgency.
He was better as an engineer than a communicator.
I'd bet that this letter was written longhand or dictated and handed to a typist. That may be part of the reason why.
At a meeting, if the organizer chooses to move on to another topic after you present an issue, you have no choice but to go along. Here's a Shuttle Flight Readiness Review at Kennedy Space Center:
http://appel.nasa.gov/wp-content/uploads/sites/2/2010/12/06p...
It's hard to stop a train like that.
Currently, the (large) meeting room at NASA JSC where flight decisions are made has many big red hand pieces at which anyone who has an issue can break in.
Don't forget this warning was to a VP of Engineering and was referencing previous issues that were being worked on. There seemed like plenty of context there to me.
Why am I heartened to see that someone foresaw a lethal accident and was ignored? Because it was foreseen, and the consequences understood, with clarity. Getting people to take clear warnings seriously seems a more easily solved problem than getting us to be able to recognize the danger in the first place. A single person in management, or a few people, being dense is fixable. Groupthink where everyone assumes someone else is checking for problems and no one does is harder to fix.
Now, just because it's an easier problem doesn't make it an EASY problem, but still, easier.
If there are any high level managers here, please tell me, does it seem like your people are constantly alerting you of dire risks? Does it feel like you are inundated with worriers?
http://www.npr.org/sections/thetwo-way/2012/02/06/146490064/...
And an interview with one of Boisjoly's colleauges:
http://www.npr.org/sections/thetwo-way/2016/01/28/464744781/...
I think the way to look at it is from the point of view that people have before the event happens. You also weigh in all the warnings that you are receiving.
No matter what you build, if it's complex enough you're always going to have individual predicting doom. The challenging part is filtering the signal from the noise and owning the decisions you make.
They knew the o-rings were being eroded away during the flight, but the secondary o-ring was 'squishy' enough to fill in the gap and prevent the erosion from actually destroying the vehicle. While the erosion was unexpected, they figured the 'backup' was doing its job, and actually ended up increasing the predicted safety margin (i.e. it's only working 1/5th of the way through, so we have a 500% safety margin, yay! despite the fact that any erosion was unexpected in first place)
The problem was, the cold made the secondary o-ring stiff enough that it didn't 'squish' as much as it had in previous launches, so the o-ring failed completely.
Seems not very different from how companies are managed 30 years later.
Lets see how it will turn out now.
Edit: And yes, it is sarcasm, nothing changed or is going to change.
It's a real PITA to engineer safe systems (see e.g. IEC 61508 and ISO 13849 in industrial automation), but it saves lives, and if you're in a position where Sales, Production, etc. is trying to get you to rush the Engineering work so they can make deadline, you've got to find the backbone to say "no," even if it hurts you professionally.
It's actually really hard to warn people. Warn them loudly and strongly and they think you're scaremongering and being unnecessarily negative. Warn them quietly, and nobody listens. Warn them just right, and they'll take it under consideration, but go ahead anyway.
When of course the inevitable happens, as the guy who predicted doom, you'll be blamed, because "it wouldn't have happened if you hadn't made a self fulfilling prophecy".
Right... and maybe this is a problem with the authors of the note rather than the recipients? Know how to communicate to your target audience.