RE: Real-World Ethical Questions

Subject: RE: Real-World Ethical Questions
From: "Robert Plamondon" <robert -at- plamondon -dot- com>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Tue, 15 Apr 2003 12:09:36 -0700


Here's a similar situation to one of the real-world ethical questions that
came up with a recent client (and which serves as my excuse -- for what it's
worth -- for being over-definite in a previous posting):

I was minding my own business, documenting an IC with a security feature,
the nature of which is not important for this narrative. I noticed that the
spec seemed to leave one base uncovered. I went to the engineer most
familiar with the chip and pointed this potential flaw to him.

He quickly verified its existence and immediately reported it to the
bug-tracking database. This automatically sent e-mails to anyone inside the
company who cared to sign up for notification of new bug reports. He did not
tell his boss (the engineering manager) or the marketing project manager
first -- policy was to report problems immediately and let the chips fall
where they may. No secrets. No spin.

A security flaw is bad news. It got everyone's attention.

I was told not to document the bug in the data book. Not that I would have
anyway: A data book is not supposed to be a series of interim bulletins from
the front; it's supposed to document how the chip will work when it's all
grown up. If the bug ended up fixed (which, in the end, it did), little or
no change was required. Otherwise, it all depended on exactly how we backed
off from our original feature list.

In dealing with the problem, the sequence of events was:

* Discover the potential problem and ask an engineer his opinion about it
(done by me).

* Verify the problem and alert everyone of its existence via the
bug-tracking database and weekly multi-departmental team meetings. (Done by
the engineer.)

* Figure out what's going on. (Assigned by the engineering manager, with all
interested parties sticking their oars in.)

* Figure out what to do about it. (Long multidepartmental wrangle.)

* Alert the customers about those parts of the problem that are visible to
them, and what we expect to do about it. This usually takes the form of an
errata sheet. (Another wrangle where people from all departments got a
vote.)

* Alter the main-line documentation to reflect the way the chip will behave
once all the fixes are applied. If the fixes will take some time, a waiver
will also have to be prepared for the interim, divulging the differences
between the chip's documented and actual behavior. (Yet another process
where everybody got a vote.)

Inside this entire process, the one way for someone to really get himself
fired would have been to try to hush up the existence of the bug. Everything
else involved so much peer discussion and peer review that it would have
been hard to get into real trouble.

No one ever suggested concealing the bug from the customers or folks inside
the company. The worst we did was to avoid making interim reports until we
had a pretty good understanding of what was going on. (Had the product been
in production, rather than in the engineering prototype stage, no doubt
something would have disclosed to the customers sooner.)

Security problems need to be handled delicately, since you don't want to
divulge detailed instructions about how to hack your product, while at the
same time you have an obligation to your customers. Often this means that
the public documentation never mentions security problems, but a second
document that reveals the flaws is pressed into the customers' hands before
their purchase orders are accepted. Of course, this can't be done without
the knowledge of the sales force.

-- Robert
--
Robert Plamondon
President, High-Tech Technical Writing
robert -at- plamondon -dot- com
http://www.plamondon.com/HIGHTECH/homepage.html
"We're Looking for a Few Good Clients"



^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Purchase RoboHelp X3 in April and receive a $100 mail-in
rebate, plus FREE RoboScreenCapture and WebHelp Merge Module.
Order here: http://www.ehelp.com/techwr-l/


Help celebrate TECHWR-L's 10th Anniversary starting this month!
Check out the contests at http://www.raycomm.com/techwhirl/special/contests/
Happy birthday to you, happy birthday to you, happy birthday TECHWR-L....

---
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:
RE: Real-World Ethical Questions: From: John Posada

Previous by Author: RE: Real-World Ethical Questions
Next by Author: RE: When is a Shim Not a Shim?
Previous by Thread: RE: Real-World Ethical Questions
Next by Thread: Employment, Tech Companies in LA


What this post helpful? Share it with friends and colleagues:


Sponsored Ads