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.
Subject:Re: Documenting A Moving Target From:WandaJane Phillips <wandajp -at- ANDYNE -dot- ON -dot- CA> Date:Tue, 20 Feb 1996 17:08:03 -0500
Karen Gwynn/Datatel wrote:
> Problem: I am trying to document a product that is still being developed
> HELP! What do other people do? Do other software companies build in time at the
> end of the development cycle for doc to catch up? Whose responsibility is it to
> notify doc of all these changes as they occur (that's the other thing; I
> happened to find this item, no one told me of the change).Karen, we do a couple of different things to help control this mess.
1) we define an interface freeze date, sometimes feature by feature.
This rarely works.
2) we meet regularly.
3) a third party (QA) verify the document/software
4) we write release notes, copious release notes and then use the
information as a basis for correcting the docs.
but then, sometimes we can't decide whether it *supposed* to work the
way the docs say or the way it does!!
All in all, not a very efficient process. I'd like to try the approach
that Mathematica used (I hear) for a product. They wrote the manual and
gave it to the developers as specs for the product. Such a rush!
Senior Technical Writer -- Pablo
Usual disclaimers in effect