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.
> Sorry, I'm going to have to disagree with you here. Most documentation
> flaws I've encountered were directly due to lack of the necessary
> information.
Isn't it a bit presumptuous to suggest you know more about my experience
than I do? Perhaps we can agree that lack of the necessary information is
typically the root of the problem. In my experience that lack is usually
directly due to no specs, no market requirements, and no software
development process or, as you choose to put it, "lack of necessary
information." None of those things had to be rigidly-controlled documents
that no one reads. Memos or emails addressing those topics can serve the
purpose, but someone has to define what is being built and for whom.
> On the "bad" projects where I've either worked or been called in to fix,
> the writers were often woefully uninformed about the product. Worse yet,
> they were uninterested in playing with the product, becoming users,
> trying to set it up and make it work as intended, or anything you might
> assume they'd need to do. Instead, they were more interested in having
> information spoon-fed to them by functional specs, developers, and other
> "expert" sources.
I have also worked with such writers but most often those writers were
uninformed and uninterested because an engineering organization that that
coded by the seat of its pants dumped a poorly conceived piece of software
on them shortly before release and sat back self-satisfied that the job was
done. Sometimes the laziness Andrew sometimes refers to is attributed to
the wrong place.
> As I said before, on any project, get the information and content right,
> and then we can talk about having fun with processes.
And as I said before, a reliable way to get the information and content
right is to have a process that you know will produce it reliably and
efficiently. Most objections I have encountered to processes have come from
folks who object to any sort of disciplined approach to the work. They want
things their way, and that's the long and short of it.
There ARE processes that add value. I have worked with them.
Trying to develop a product without a process that everyone understands and
has confidence in is like an NFL team taking the field for the opening
kickoff with vaguely-conceived plays and little idea of how to execute them.
