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.
> The old saw "good, fast, cheap: pick two" sounds good, but in the quality
> methodology, it doesn't hold.
>
> [SNIP]
>
> But there's another model, expounded by quality experts such as Deming and
> Crosby: Do it right the first time. If you do things right the first time,
> how much does it cost to fix errors? Nothing. How long does correction take?
> No time. The key, then, is to do things right the first time.
I like that idea: "Do it right the first time." I guess in my perfect
world, the one where they write the requirements before they write the
specs, and they write a design document before they do the coding. And I
write to the same set of documents that the developers write to, and all of
our work goes to testing at the same time and testing tests both code and
documentation against the requirements, which are also always kept up to
date.
Yeah, if I lived in that world I would want to "do it right the first time."
Actually, in the world I live in I want to do it right the first time, and I
think I do. But you know what? They change the user interface without
telling me. Can you believe it? What I did was right when I did it, but
they made last minute changes. I don't know why; they didn't tell me. Now
I have to redo all the screen captures and rewrite (or at least retest) all
the procedures, rewriting those that were changed. Otherwise, the document
is wrong. Now, the document was right, but they changed the system, and now
it's wrong, and I have to redo it.
Gee, I guess I should have been smart enough to realize that they were going
to make that change (without telling me) and not done the documentation when
the system was ready for me to do that.
(Pardon me if I don't think the ivory tower resembles the world I'm working
in.)