TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Documenting that bad tech writing kills people (ex fear and loathing thread)
Subject:Documenting that bad tech writing kills people (ex fear and loathing thread) From:"Bill Hall" <bill -dot- hall -at- hotkey -dot- net -dot- au> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Sun, 11 May 2003 17:14:29 +1000
Rick Lippincott wrote re bad tech writing killing people:
>Of course, it's _possible_ for a tech writer to kill someone with
incompetence.
It's more than possible. It's happened. Off the top of my head, I can think
of at least a half-dozen fatal aircraft crashes that have been attributed to
faults in the documentation. I'm not talking about small, general aviation
(i.e. "Cessna and Piper Cub") aircraft, I mean airliners or large military
transports.
---------
I say, it would be well worth compiling a hall of shame of documentation
related disasters - especially with reference to reports and other documents
detailing the circumstances. We all know they happen, and I've made a couple
of stabs at doing it myself, but the only cases I have found in the
Australian environment are the two I mentioned - Longford and Westralia -
where the documents hadn't been written or were there but not used. Longford
issues are supported by the findings of a Royal Commission and Westralia by
the Board of Inquiry - both of which were published.
Aerospace is a good field for cases because of the very thorough accident
investigations that follow. I have previously tried to compile such a list
myself, but ended up with so few cases that it wasn't particularly useful.
The list would be useful in several ways - justification for budgets for
more and better documentation, reminders to authors and editors, emphasising
the importance of competence, and perhaps to highlight specific kinds of
errors made in the documentation process.
The list should not be limited to bad writing, but should also include bad
processes (e.g., failures to update documents with change pages), bad
distribution/availability (existing documents weren't available where and
when needed - as was partly the case with Longford) and so on.
Ideally the hall of shame should be posted on a site like Techwrl where
anyone can reference it via a URL when some backup is needed.
Unfortunately, if we hide our mistakes we can't learn from them.
Bill Hall
Documentation Systems Specialist
Strategy and Development
Tenix Defence
Williamstown, Vic. 3016
bill -dot- hall -at- tenix -dot- com
URL: http://www.tenix.com
Honorary Research Fellow
Knowledge Management Lab
School of Information Management & Systems
Monash University
Caulfield East, Vic. 3145
URL: http://www.sims.monash.edu.au/research/km/
---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
