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.
It shocked me deeply when Wayne Douglass said:
> You can't write a manual that's better than the product.
Then, to make matters worse, Alexia Prendergast said:
> Couldn't agree with Wayne more on this one
It's a disturbing feeling to disagree with Wayne (witty, sensible, a
Unix guy) and Alexia (not a Unix gal, but witty and even more sensible),
but here goes:
Aren't you both confusing 'product' with 'software'? The software isn't
the product. The software, the manual, installation procedure, support,
and other things all make up the product. Whatever the programmers
think, customers don't buy software, they buy a product.
Can the manual be better than the product? It's a meaningless apples-
and-oranges comparison. Can the manual compensate for deficiencies in
the software and so make the product better? Yes, isn't that what we
try to do all the time?
The dizzy feeling began to subside when Alexia went on to say:
> -- good docs will uncover flawed designs. I've learned with time
> that when I really struggle to make a section of a book sound right,
> it's usually a design problem.
Right on.
Next thing you know I'll be agreeing with something said by J... --
well, never mind who.
Regards
---
Stuart "at least Geoff Hart didn't go along with them" Burnfield
Consolidated Phlogiston Pty Ltd mailto:slb -at- fs -dot- com -dot- au
