Re: Why docs aren't tested

["Westra, Kayla L." <13718westr -at- KCPBLDG01 -dot- BV -dot- COM>]

Karla McMaster writes, "Do we always have to come in at the last minute?"

My experiences with documentation are a bit different, as my company
produces software as a secondary venture (to support the power plants we
design).  I've been involved in the documentation for the manuals about six
months.  While it is easier to become involved in the beginning of the
process, cold hard fact is that they don't consider documentation until the
product is nearly finished.  I've worked with a couple of excellent
development teams who have been happy to answer all my questions, so it
hasn't been a major problem.  Still, I wonder how much information I am
missing.

Still, I think my strongest asset is that I'm _not_ a programmer.  When I'm
working my way through a program to write a user's manual, I don't skip
steps because I don't have the background to "just know that it works that
way."  I've heard this called the "clear only if known" concept.
 Engineers/programmers tend to assume you know how to get there from here.

A side note.  About a third of my time is devoted to documentation, and we
have one technical editor who works full-time writing manuals.  He's even
developing a process manual so that future development efforts will be more
organized.    This is definitely a step in the right direction.

Kayla Westra, technical editor
Black & Veatch
13718westr -at- kcpbldg01 -dot- bv -dot- com
"Treasures have no value unless you share them."