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.
In a completely different context, software quality, Mark Wiley wrote:
-----------------------------
Customers sometimes won't wait for or pay for the activities
that would significantly improve product quality. If they
buy someone else's product while you are improving the
quality of yours, that has a real impact on both companies
involved.
Mark S. Wiley
I think it is much more broadly applicable than just software quality
narrowly considered as the number or impact of bugs or the usability
of the GUI. In particular I think it applies also to documentation.
Sometimes, "If a thing is worth doing, it is worth doing poorly."
(Rather than not doing it at all.)
That said, I agree, in principle, with most of your other comments, disagree
with some:
< 1. fail to commit adequate R&D resources to keeping product development
< AHEAD of the competition.
There are MANY claimants on finite resources. There are successful
high-tech companies that spend ~6% of revenues on R&D and unsuccessful
ones that spend <10 or 12% on R&D.
< 2. fail to allow sufficient resources to ensure that documentation
proceeds WITH development rather than AFTER development.
Partly a resource problem, partly a process/discipline problem, partly
competing claims to resources. Is a lousy manual better than none? Do they
know what costs they incurr in support calls because of lousy manuals? Do
customers use good manuals more and more effectively than they use lousy
manuals?
< 3. believe that documentation is just a side issue, not as important
< an element of the product as the GUI.
But, of course, this is true. Documentation is NOT as important
as the GUI.
< 4. would never even consider delaying the release of a product
< because the documentation wasn't ready.
See above.
< ...those of us in the documentation process must
< stop kowtowing to poor management practices and speak up.
< One of the things I've always said is that a big part of
< my job...is to be an advocate for the users. We don't serve
< the users by giving them poor product documentation.
One of the major management jobs is balancing competing interests and
requirements, for money, for delivery date vs function, for deliver
date vs quality, for delivery date vs quality of documentation, ...
Yes, sometimes, or often, some, or most, managers make poor decisions.
Usually the very poorest ones lead to the demise of the manager or
the company. The midly poor ones lead to customer and
employee unhappiness.
John Ahlstrom
jahlstrom -at- cisco -dot- com
"Oh, I never get done. I just keep polishing till
they come and take it away."
Dale Carnegie Commercial
John Ahlstrom
jahlstrom -at- cisco -dot- com
TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send commands
to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
Search the archives at http://www.documentation.com/ or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html
