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.
I appreciated the link to the article about the team of NASA/contractor
programmers that write and maintain the Shuttle on-board computer
software. A colleague of mine used to work on that team; and I am an
employee of Lockheed Martin.
This NASA team writes near-perfect code because peoples' lives depend on
the quality of their programs. What the article fails to make explicit
is how expensive and tedious this kind of software development is. Code
improvements take place at glacial speed. Imagine that you want to make
a minor change in a single line of code, one that you're confident will
only improve the program. Such a change may likely take more than a
year--if ever--to make because of the lengthy paperwork and approval
process. This is great, indeed necessary, for some applications, such as
the shuttle and other life-critical systems. On the other hand, no one
dies when MS Word crashes. Thank God. ;-)
My point is, while it's great that some teams write error-free code, one
might not necessarily have the right mindset to tolerate the bureaucracy
that goes along with that kind organization. You have to be somewhat
detached and extremely patient to endure this kind of environment.
Writing documentation is much like programming. Give me more staff or
more time, or both, and I can probably produce better documentation. Get
the SMEs to adhere to a regular schedule and ensure they provide all of
the needed information and I can guarantee even better documentation.
Make a product very slowly and make changes only through a detailed,
well-documented process, and my technical writing team might even get
bored for lack of a challenge. :-) On the other and, if we use this
approach, our competition will have a product out the door--albeit one
with bugs and less-than-perfect documentation, a decade ahead of us.
-Mike
--
Michael Andrew Uhl (mailto:uhl -dot- mike -at- epa -dot- gov)
Lockheed Martin - U.S. EPA Scientific Visualization Center
Ph. (office) 919.541.4283; 919.541.3716 (lab)
P.O. Box 14365 Research Triangle Park, NC 27709
