RE: The Problem With Keeping It Plain And Simple? (take II)

Subject: RE: The Problem With Keeping It Plain And Simple? (take II)
From: mlist -at- safenet-inc -dot- com
To: techwr-l -at- lists -dot- techwr-l -dot- com
Date: Mon, 24 Apr 2006 16:55:57 -0400

This thread annoys me. :-)

> -----Original Message-----
> From: Bill Swallow [mailto:techcommdood -at- gmail -dot- com]

> I don't think the analogy holds. Plus, depending on the type of
> company and type of work you perform as a technical writer, the type
> of estimates you will need to provide (and the metrics used to back
> them) will vary greatly.
> On 4/24/06, Peter Sturgeon <prsturgeon -at- yahoo -dot- com> wrote:
> > How do distilleries measure production? We seem to be in a
> similar field, starting with lots of stuff and boiling it
> down. Or are we more like maple syrup producers?

When I'm writing new docs for a new product (rare), I'm
distilling a lot of info from many sources into notes,
which I then expand into an actual customer-oriented
document... which I then edit for MY reasons, if I have
time, and edit for reasons of final product turning out
different that what was originally conceived, described,
"planned"... whatever words the specifying people and
the designing people use to describe how they pull stuff
out of hats... (hey, it's an elipsis kind of day, OK?).

Most of my time is spent revising and editing my existing
docs for new product versions. That means adding new
pages for stuff they've added - or for stuff that customers
and support people wished I'd included in the original. It
means editing pages for product-stuff that has changed.
It means deleting pages for product attributes and old
commmands, etc., that have been removed or superseded.

Or, lately, I'm digging into existing documents from
the writers who were let go when we purchased yet
another small company, and are now issuing a new
version of whatever product(s) that company previously
sold. Sometimes, I'm just adding/tweaking because the
previous writer did good docs; sometimes
I'm slashing and burning and doing major re-write
because the existing docs are not very good.

I've yet to meet a metric that would adequately reflect
that sort of thing.

How the mumble-de-mumble do you decide how much writing
you are going to do when you have not yet reviewed the
existing docs?
How do you estimate how long your review will take, if
the product update specs are not ready yet, so you don't
yet know what's expected to change?

I often do stuff "the lazy way", but I get things done,
normally on time and correct enough that QA has very
few things to remark on. I do it all myself, because I
am a local department-of-one, similar to many of you
captives and to most contractors, I'd expect.

I hereby promise to harbor a profound and irremediable
disrespect for anybody who comes to me demanding that
kind of brain-dead metric. There would, of course,
be no point attempting to persuade/argue them out of
their notions... they being brain-dead, and all.

Kevin </ire>

The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it.

WebWorks ePublisher Pro for Word features support for every major Help
format plus PDF, HTML and more. Flexible, precise, and efficient content
delivery. Try it today!.

Doc-To-Help includes a one-click RoboHelp project converter. It's that easy. Watch the demo at

You are currently subscribed to TECHWR-L as archive -at- infoinfocus -dot- com -dot-

To unsubscribe send a blank email to
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit

To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit for more resources and info.

Previous by Author: What sounds better than "as-is", but means the same?
Next by Author: RE: Metrics for Technical Writing.
Previous by Thread: RE: Metrics for Technical Writing.
Next by Thread: online masters

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

Sponsored Ads