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: Dredging for dept information From:Eric Ray <ejray -at- raycomm -dot- com> To:Elna Tymes <etymes -at- lts -dot- com> Date:Mon, 29 Nov 1999 05:56:52 -0700
Elna Tymes wrote:
> While I tend to agree that *any* information is better than none, I must point out that engineers and programmers tend to
> forget about documenting anything unless consistently reminded that documentation is part of the product. And while
> "steamrollering" project people into doing specifications and other wonderful things might also create a lot of
> long-simmering resentment, the bottom line is that something gets created by which one can see what the product is
> intended to do. I'd advise a little more tact and discretion, but I'm generally after results, too.
Good point! Finding the line between effective steamrollering and
fostering
resentment is a tricky one, though. If everyone is focused on the same
goal,
it helps.
> I suspect the original writer's previous experience was in a development environment where specifications or something
> like that were required, and thus he 'grew up' believing that this is normal. <chuckle> We should be so lucky. The
> truth is that we still scramble for source information in any form we can get it - ranging from tape-recording the
> ramblings of some programmer or engineer to working with the product and then asking questions to sitting in on
> development arguments/meetings, etc. Sure, it would be nice to have specifications as source material, and project
> people should generate them - but there are a lot of 'shoulds' that don't get followed in the real world.
And, even when specs exist at some early (mythical) stage in the
process, they often
introduce more confusion than they solve. If the specs (as written)
aren't updated as
the product design evolves, they just introduce one more incorrect
datapoint for
writers to filter out, and this problem gets worse as development
continues.
That is, a spec that's 80% accurate when coding begins is a great
starting point
for writers. A spec that's 90% accurate at alpha is somewhat helpful,
but the
10% will bite the writers and QA staff (but significantly, not the
engineers).
A spec that's 95% accurate at beta is nearly worthless to writers, as
the
devil is in the details and there's no telling which 5% to ignore, thus
leaving
the entire document suspect. But you knew that!
