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: writing around desgin flaws From:Joyce Flaherty <flahertj -at- SMTPGW -dot- LIEBERT -dot- COM> Date:Thu, 16 Nov 1995 13:35:48 EST
RE: how to write around serious design flaws for which there is
no logical explanation
======================
I answered this post privately a few days ago. Now I think
that there is enough interest and it is important enough to
answer to the list.
First, suggest to your top management that they stop sending
your programmers to the Gates School of Programming.
Seriously, you should never have to write around a *serious* design
flaw. If you can't fix the flaw, then redesign the program. The
product should not go to market. If your company continues to
support debugging in the field, then find another employer. It's
a matter of self respect.
Val Tassari addressed the topic much more comprehensively that I.
She suggests an organization structure that precludes *serious*
design flaws. Unfortunately, not all writers are in a position
to bring about organization change.
hope this helps,
joyce flaherty
______________________________ Reply Separator _________________________________
Subject: writing around desgin flaws
-> not talking about a few bugs in a program. I'm interested in how people
-> write around serious flaws for which there is no logical explanation. And,
-> for the sake of discussion, let's assume that there is no way to get rid of
-> these design flaws.