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.
Since nobody else has mentioned this yet:
"I love deadlines. I like the whooshing sound they make as they fly by."
Douglas Adams
In my software development and documentation experience, "good enough"
changes depending on where you are in the development cycle.
It's a given that all software and content has bugs, as much as you try to
eliminate all of them. The question is not, "Do you know about the bugs
before you ship the product and doc?" You usually know about many of them
when you ship it.
The question is, "Are any of the bugs we've identified stop-ship issues?"
Most of the shops I've worked in used a triage system to evaluate bugs when
we were in the release phase (during the last days, sometimes a week or so,
before the scheduled ship date), and we had strict criteria for judging
whether a bug (in the application or the documentation) was a stop-ship
issue. For example, these were stop-ship issues: Does it corrupt the user's
data? Does it crash the system? Does it cause death and dismemberment? (OK,
that last one is an exaggeration; I worked on financial applications.)
It had to be major to prevent the team from meeting that deadline. And I'm
happy to say that we never delayed a release because the doc wasn't ready.
(I will admit to breathing many sighs of relief when some other team caused
a delay, because that gave the doc team more time to clean things up.)
Prior to that phase of the project, we aimed for perfection. But during that
release phase, when triage was happening, if a bug wasn't deemed a stop-ship
issue--for example, a form field that didn't align with the rest of the
fields, or a dangling modifier on page 27--it was deemed "good enough; we'll
fix it when we release the next patch."
-----Original Message-----
From: techwr-l-bounces+royj=writingclearandsimple -dot- com -at- lists -dot- techwr-l -dot- com
[mailto:techwr-l-bounces+royj=writingclearandsimple -dot- com -at- lists -dot- techwr-l -dot- com]
On Behalf Of Cardimon, Craig
Sent: Tuesday, September 30, 2008 10:59 AM
To: Victoria Wroblewski
Cc: Techwr-l
Subject: RE: "Good enough"
I come at TW from a background in newspapers. You don't miss deadlines in
the news business. That's why they're called "dead lines." Cross them and
you're as good as dead. Your business is, anyway.
Sometimes people have a tendency to think that with an MA in English, I'm
focused on literature and punctuation. I can be if the situation calls for
it. In business, I'm focused on deadlines and getting the product out the
door.
The master's carries a lot of weight, but my experience writing/editing copy
and meeting deadlines is the icing on the cake that really sells the
academic knowledge promised by the degree.
ComponentOne Doc-To-Help gives you everything you need to author and
publish quality Help, Web, and print content. Perfect for technical
authors, developers, and policy writers. Download a FREE trial. http://www.componentone.com/DocToHelp/
True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
