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
> To: TECHWR-L
> 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 http://www.ehelp.com/techwr. 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
http://www.raycomm.com/techwhirl/ for more resources and info.



References:
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