Re: acceptable error rates

[Arlen -dot- P -dot- Walker -at- JCI -dot- COM]

     Our company is presently developing
     a list of goals for our tech writers.  One
     area that they would like to have better defined is the
     industry standard for the acceptable rate of typographical
     errors in a document.

Does the phrase "Zero Defects" ring a bell? ;{>}

Seriously, I'd be leery of any such measurement. First, when is the
measurement going to be made? If before release, then the typos should be
fixed and, as noted by someone else, it should be called "proofreading."

Secondly, how is such a measurement going to be possible to make
accurately? "The Last Typo" is a mythical beast; negative propositions
cannot be proven. It is not possible to confidently assert there are *no*
typos in any document of reasonably large size and complexity. It is only
possible to assert that one hasn't been found, yet. Programs cannot be
relied upon; any functional spelling checker will accept "god" when what
you wanted to write was "good." (Or likewise with "rod" and "red.") And
people? Well, how many times have we *all* stared a typo in the face and
not recognized it?

Thirdly, not all typos are created equal. There's the famous example of the
"Adulterous Bible," a version of the King James in which a printing error
left the "not" out of "Thou shalt not commit adultery." It's only one typo
out of a *very* large doc, well within *any* numerical standard you might
set. Yet it caused a complete and expensive recall of the entire print run.

And fourth, there's a philosophical problem here. You cannot inspect
quality into a product. Any quality engineer worth his salt will tell you
that inspectors are a waste of resources. Quality needs to be designed into
the product via the process that creates it.

From the measurement you've suggested it sounds like your company is trying
to either improve the quality of the docs or document the existing quality
of the docs by adding an inspection process. While the aim is laudable, I
think it's the wrong way to go.

No pre-set amount of typos are acceptable; aim for perfection, knowing full
well that you'll fall short of the mark, but hoping all the time that
you'll at least achieve something useful.

Numbers are wonderfully mind-numbing. Given a metric, we can *always* find
a way to meet or exceed it, usually rendering the metric meaningless along
the way (especially if people's paychecks are hitched to it). The tendency
is to focus on the numbers, and the reason for their existence in the first
place is then left to twist in the wind. If you use typos as a metric,
you're likely to wind up with wonderfully spelled, but completely
impenetrable, docs.

If you *have* to have a number, I'd suggest measuring the quality of docs
by the number of support calls. If a section of the docs seems to get more
calls for help than another, then that's the section you should turn to
first. If you're writing internal docs, do spot checks of your users; the
number who actually use what you wrote, rather than a "cheat sheet" they
have handed down to them from their forerunners, is also helpful. If you
catch someone using such a cheat sheet, don't make a big deal over it; just
ask to make a copy of it, then study it to find what *it* has that *your*
version didn't have.

I'm reminded of a story from Network Computing (and numerous other places):
A helicopter pilot flying over Seattle had a malfunction, and his
navigation and communication equipment were disabled. Due to the usual
Seattle cloud cover, he couldn't figure out where he was, or how to get
back to the airport. He spotted a nearby tall building and circled it,
holding up a hand-made sign saying "Where Am I?"

The inhabitants of the building scurried around and created a large sign,
which they held up in the window for his benefit. "You're in a helicopter."
The pilot nodded and waved, looked down at his map, plotted a course, found
the airport and landed safely.

After they landed, the copilot asked him how that answer helped determine
their position. The pilot replied, "It meant the building was the Microsoft
Building, because like their tech support, they gave an answer which was
clear, technically correct, and completely useless!"

It axiomatic, if you want something to improve, measure it. But a lot of
thought should be given to what precisely it is that you're trying to
improve. Yes, it's a Good Thing to reduce typos. But typos aren't the
problem; they may not even be related to the *real* problem. No mere typo
measurement can measure the readability of a doc, or its usefulness. And,
in the ballpark we play in, utility is the *only* clear measure of what
we're supposed to be doing.

Have fun,
Arlen
Chief Managing Director In Charge, Department of Redundancy Department
DNRC 224

Arlen -dot- P -dot- Walker -at- JCI -dot- Com
----------------------------------------------
In God we trust; all others must provide data.
----------------------------------------------
Opinions expressed are mine and mine alone.
If JCI had an opinion on this, they'd hire someone else to deliver it.