RE: When it is right to be wrong?

Subject: RE: When it is right to be wrong?
From: "Darren Barefoot" <darren -dot- barefoot -at- capeclear -dot- com>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Wed, 6 Feb 2002 16:13:39 -0000

Well, I don't want to enter into a whole bunch of mathematics here, but
the way I see it is as follows:

You can have:

A) All the features documented, with 90% of the documentation correct.

B) Some of the features documented, with 100% of the docs correct.

Let's say I'm using a tool with 10 components. In scenario A, I can
learn something about all 10 components, and 90% of what I read will be
accurate. In scenario B, I might be able to learn something about 7
components. At the end of the day, if I want to use the other 3
components, I'm pooched. Scenario A may waste your time a bit, but
scenario B may prevent you from proceeding entirely. Besides, in
scenario A, I might blissfully use the tool for years without
discovering that the docs are inaccurate.

Speaking abstractly, this isn't particularly applicable. In real world
cases, I actually tend to a combination of getting it done and getting
it right. Sometimes if I don't have time for both, I'll skip some bits
that are the lowest priority to accurately complete bits that seem
important. Other times I'll feel a need to write something about
everything and let the chips fall where they may. DB.

> -----Original Message-----
> From: bounce-techwr-l-65243 -at- lists -dot- raycomm -dot- com
> [mailto:bounce-techwr-l-65243 -at- lists -dot- raycomm -dot- com] On Behalf Of
> John Cornellier
> Sent: 06 February 2002 16:01
> Subject: When it is right to be wrong?
> A little while ago [Darren Barefoot, I think] wrote:
> "Get it done, then get it right, then get it pretty. ... I'd
> rather have a complete documentation set that's 90% accurate
> than an incomplete doc set that's 100% accurate."
> I agree about the pretty part. But I can't think of any
> situation where inaccurate documentation is better than no
> documentation.
> I read "90% accurate" as meaning "10% inaccurate".
> Inaccurate doc is worse than no doc 'cause you waste your
> time with it. Plus it causes bad will and makes users
> distrust documentation (don't we all know it).
> Dunno, maybe I lack vision. Could someone write an article
> for the STC mag "Adding Value With Your Inaccurate Documentation"?
> John Cornellier

Did you know you can get RoboHelp certified?
To learn how, visit Be sure to also check out
our special pricing offers and promotions for RoboHelp 2002.

You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit for more resources and info.

When it is right to be wrong?: From: John Cornellier

Previous by Author: Batch saving FrameMaker files as RTF
Next by Author: I can't imagine where this portrayal came from...
Previous by Thread: When it is right to be wrong?
Next by Thread: RE: When it is right to be wrong?

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

Sponsored Ads

Sponsored Ads