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.
At 09:06 AM -0800 3/9/99, Andrew Plato is alleged to have typed in my
copy of the digest:
> Pretty much the same story for the military and NASA. These
> organizations are willing to pay a price for formalization because
> lives are at stake.
> However, in the world of superfast product development in software and
> the Internet, no lives are at stake. Nobody has been killed because
> Ebay used Arial instead of Times New Roman.
Not for that particular reason, but there are examples of software
1) The infamous Therac-25 radiation therapy machine which caused
patients' deaths before the cause came to light. A programmer's
shortcut used for debugging stayed in the shipping product, and an
undocumented key combination at the controls caused the machine to
output deadly levels of radiation, instead of the "theraputic"
Perhaps a good tech writer working with the design and programmer
team might have been able to point out the issues surrounding that
poor HCI choice of that key combination, or noticed it was still in
the shipping code, or even documented it very clearly in the final
manual (Of course, using proper spelling and grammar, keeping close
to the "Roman Law" of the approved style guide, and...). But only if
there was a good relationship between the writer and the SMEs and
programmers. And only if the HCI really wanted to change....
2) The Patriot missile battery that missed the incoming scud missile
during the "Gulf War" had some creeping rounding errors in its
software, which caused it to slowly lose tiny fractions of a second
while it was active. It had drifted about one third of a second off
when that scud missile came in, and was missed by over half a
kilometer. To correct for the time drift, the system had to be
rebooted, which took the anti-missile battery off-line for an
unacceptable amount of time in that situation.
Again, a good tech writer (using good interpersonal skills, proper
grammar, the correct long-document software tool, having intimate
knowledge of on-line help systems, and multiple copies of their
resume in various formats and mediums...) could have pointed out the
potential problems that such a reboot might cause. Then happily found
a new job for better pay after they were fired...
My point here is that these were likely very formalized companies
which made these products, but it really comes down to working well
as a group to attain the goal. Strict formalization does not
guarantee products which are of the needed quality. It IS all about
being able to look beyond your tiny piece of the picture, while
making certain your piece is still done well and fits in well with
the others. If you don't/aren't aware of how your piece fits in, the
likelihood of problems increase, and then we start the
"The main thing is to keep the main thing the main thing." And it's
very hard to do, wherever you work.
Thanks for another thought-provoking post, Andrew, and for the new
.sig file :-)
Greg Hanek ghanek -at- indiana -dot- edu
"Yeah, I am a big dork with a loud mouth and a seriously over-inflated
opinion of myself. Hey, you might have to work with a jerk like me
someday. Think of this as training." A. Plato, but it coulda been me!