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