When should the Tech Writer get into the act?

[Thom Remington <remingtf -at- FREENET -dot- SCRI -dot- FSU -dot- EDU>]

A recent conversation started with the question of when the tech writer
should become involved in documenting software. A respondent pointed out
that failure to become involved AT THE BEGINNING OF THE DESIGN STAGE
could lead to many undesirable consequences.

I couldn't agree more. I don't do software documentation, or I do very
little of it. I do environmental documents with a bunch of engineers.
Possibly the biggest accomplishment of my career so far has been to
convince them to get me involved at the beginning of the development of a
document.

In the past, an engineer would write something and pass it along to a
tech writer to "clean it up." This is closely related to documenting a
bad software design. One thing I found was that the engineers would
defend their *words* once they were on paper. By getting in there
*before* words got on paper, I circumvented that battling. Yes, we do
have discussions - sometimes even heated ones - about technical content,
but we don't argue (much) about words any more.

In the stuff that I write, by revising our workflow, I may have increased
the amount of work that I do on each document, but only by a little bit.
The SMEs (subject-matter experts) find that their task is *much* easier
and much more pleasant. What I do is much easier and more pleasant too.
I'd rather write than rehash something someone else has written.

FWIW.....

Thom Remington
Wilmington, Delaware
REMINGTF -at- FREENET -dot- FSU -dot- EDU