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: Software development: they must let us in! From:chuck mccaffrey <cmccaffrey -at- SPYGLASS -dot- COM> Date:Mon, 28 Aug 1995 13:58:42 -0500
In article <41lmah$1ub0 -at- bubba -dot- ucc -dot- okstate -dot- edu>,
Peggy_Thompson -at- ccmail -dot- osti -dot- gov wrote:
> I'm real concerned about this picture we're all painting of
> communication lapses between software developers and
> documenters.
> The only real solutions are
> (1) for the developers to put solid work methodologies in place,
> like those espoused by the Carnegie Mellon Software Engineering
> Institute
A very good suggestion.
> (2) for the documentation team to be *formally and fully
> integrated* into the development picture--with standard means of
> communicating between developers and writers;
Also good ideas.
> feature freeze
> dates to keep the manual drafts and developing system in sync
> (we are TERRIBLE at this); and a development methodology for
> writers that parallels the software dev process
A good idea, too, but keep in mind that documentation is not software, so
while their development processes should be parallel, they are only
roughly comparable. Over-concern with the doc process may lead to a
situation where you have a process so "well-defined" that you spend more
time following the process than you do writing/editing/rewriting. You can
easily wind up with a situation where you have a process but no product.
You feel like you're doing a great job because you're "following the
process" and you're in control. But these are illusions. I've seen it
happen, and the tech writers who were so proud of their "process" were
soon out of job because they never did anything except fidget over their
process.
Having well-defined means of communication, cut-off dates, and that sort
of thing is fine. But documentation is not code so I'll say it again:
Overmuch concern about "process" may leave you with no product, which may
leave you without a job.
