The latest edition of the IET’s “Engineering & Technology” magazine looks at engineering disasters and, in doing so, provides food for thought regarding the role of documentation.
“Hard lessons” looks at ten disasters, such as the Challenger Space Shuttle, and the reasons why these disasters can occur. Looking at the disasters, I could see some common themes:
1. Poor communication. Some people knew about the issue that resulted in the disaster, but the communication lines weren’t working.
2. Poor engineering.
3. People doing stupid things.
4. Acts of God.
I believe documentation can play a role, to an extent, in minimising some disasters. If you want to improve communication channels, then documentation is a very powerful tool you can use. However, I believe it’s also useful if you want to stop people doing stupid things.
Let me explain.
In another article, “That’s not mean to happen“, they look at whether software and systems can confuse operators into doing something disastrous:
“One common problem was even given a name in the 1990s by Nasa Ames Research Center scientist Everett Palmer: a ‘kill-the-capture bust’. What happens in these is that an automatic transition between system states leads to a different outcome to what the operator expected.”
So people made mistakes because a system didn’t work in the way they expected.
Clearly, there’s a need to build a better system to stop people doing stupid things. There’s also value in good training and instructions. However, problems are not always obvious and situations can occur that no-one can predict. It’s in this area where documentation can also play a part. That’s because, in such an unpredictable event, users need explanations as to what things (could) mean, so they can make an educated decision. I believe documentation could provide such “decision support” information.