Re: Dredging for dept information

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!

Eric




Previous by Author: Re: HTML
Next by Author: ADMIN: Responsibilities Reminder
Previous by Thread: Re: Dredging for dept information
Next by Thread: Antwort: Long headings in FrameMaker


What this post helpful? Share it with friends and colleagues:

Sponsored Ads


Sponsored Ads