[zelos]

Maybe, but I don't think anyone can deny that it is an appalling slide. I count 3 spelling and grammatical errors alone.

It looks like the bad "before" example in a presentation skills workshop. This was created by engineers working on life and death issues involving billions of dollars of hardware.

[cxr]

> Maybe, but I don't think anyone can deny that it is an appalling slide. I count 3 spelling and grammatical errors alone.

The slide from the post that you're referring to (which is 16:9) is a fabricated, probably created for this post, and is not a faithful copy of the actual deck that was presented in 2003. The actual slide—complete with a Boeing watermark, sans some of the errors and presentation issues we can see in the blog post, and in 4:3, of course—can be seen in Tufte's book.

Who knows why the slide in this post was fabricated (and why the author failed to indicate this fact anywhere).

[bumby]

I agree with you, but to be charitable, this was a real-time and evolving situation where I'm willing to bet the slide was expected to be finished "yesterday"

[phicoh]

This seems to be the kind of slide made by someone without a lot of experience presenting work.

The other issue is, some people really, really, don't want to speculate.

In this case it seems that the person who made the slide probably assumed that the tile could be broken with a high enough probility. But because it was outside all available data, the slide says that we don't really know.

Of course, anybody in a position to make such a go-no-go decision should have enough experience talking to engineers, and seeing this effect in action to recognize the slide for what it is. It is really weird to conclude that based on absence of data, it is probably safe.

[bumby]

>It is really weird to conclude that based on absence of data, it is probably safe.

Considering that's exactly what happened nearly 20 years earlier with Challenger, it seems to be more common and likely the result of a number of cognitive biases. We read these with some hindsight and are disconnected from all the other pressures (schedule, budget, peer, etc.) they are dealing with at the time.

[phicoh]

That points to a far more fundamental problem. Related to information processing higher up in the organisation. Just making better slides is unlikely to solve that problem.

[bumby]

Probably correct, and I have doubts that those types of problems are easily fixed because they're rooted in human psychology. It's interesting to me that the "big" incidents seem to occur every 15-20 years, almost as if there is a new professional cohort who has to learn the hard way. I do think clear communication is a necessary, but insufficient, element of fixing that problem.

[phicoh]

One thing I wonder about with these kinds of accidents: to what extend does operational experience work its way back to requirements of components.

For example, if regularly pieces of foam are hitting the tiles after launch, was that part of the specs for the tiles to handle that? Did anybody go back, take a worst case scenario of a piece foam hitting a tile (size, speed, etc.) and verify that the tiles could handle such an impact?

[mjevans]

This could also be related to a broader tendency to promote 'performers' who are more likely to take risks or shortcuts that they might not realize involve risks as well as people that use less resources (lower safety margins, less overlapping checks etc).

It's sadly difficult to be recognized for excellence in preventing surprises, as hard as it is to quantify that.

[mirker]

One factor for why is that bringing bad news may poorly reflect on the organization, and therefore the person’s career.

[bumby]

It takes some intestinal fortitude to be in a role that is tasked with communicating information people don't want to hear. It's part of the reason NASA created it's "Safety and Mission Assurance" organization after this incident and gave them a completely different chain of command. In theory, that mitigates some of the career threat, but in practice it may be different.