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 have yet to see perfect documentation for an unflawed software
> product. Actually, I have yet to see an unflawed software product.
Why isn't a perfect document possible? IMHO, you can perfectly document
how to use a bad product to shoot yourself in the foot (or head). This
is sometimes a good way to try getting a bug fixed.
> It is even possible (not easy, but possible) to use documentation
> to make some, most, or all of the flaws or bugs look like real
> features by writing about what the flaw does, not about what
> it does not do.
I know of at least one case where "what the flaw did" was completely
trash all the work the customer did up to that point. However, I
did take your advice - I documented it. ;)
> It is possible to write documentation that makes a badly flawed
> product look less flawed.
IMHO, this is not necessarily A Good Thing. The idea is to document
how the product works, no matter how it works (or doesn't work). I
am not hired to make my boss or marketing happy. I am hired to document
how the product works.
David (The Man) Blyth
Technical Writer
Qualcomm
The usual disclaimers apply - I don't speak for QUALCOMM, they don't speak
for me....
