Re: YOU are responsible, even when YOU are not to blame (long)

Subject: Re: YOU are responsible, even when YOU are not to blame (long)
From: SteveFJong -at- aol -dot- com
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Sat, 12 Apr 2003 15:45:17 EDT

Andrew <gilliankitty -at- yahoo -dot- com> continues the discussion of root-cause
analysis and quality:

>> Example, a document has consistently wrong data about a product feature.
>> writer becomes obsessed with figuring out why he got the wrong data (or who
>> gave it to him) that he gets distracted and does not just plant his butt
in a
>> chair and fix the doc. The need to justify an error is so powerful that it
>> overrides the need to repair that error.

Has this ever happened? I asked for a citation, not a made-up counterexample
pulled out of your ear.

>> My methods assume right from the start that problems will happen.
>> Yours assumes that problems won't happen.
>> I know for a fact, problems always happen.

Strawman argument: I didn't say that. What I said was that the find-fix cycle
is inefficient, and that with good processes, errors can be avoided.
Find-and-fix is the management equivalent of the font fondling that you
decry: it's useless scrap and rework. Do you always have to have problems?
No. Notice that Japanese cars have gotten to the point where you can often
get one without *any* defects whatsoever--sometimes one or two defects, but
sometimes none. Because fixing even one defect after delivery can eat up the
entire profit margin on a car, zero defects is enormously efficient. Detroit
thought zero defects was an impossible goal; they're still working to catch
up. Considering how many steps and (and people) are involved in automobile
manufacture, how do you think they get to zero defects? By using good

>> The funny thing is, Steve, most Jap [sic] cars are now made in the US.

First, ethnic slurs have no place in this forum. Cut it out.

Second, you're otherwise correct: many Japanese cars are now built in the US;
as far as I know, they are of almost the same level of quality. The quality
process is independent of culture. (It should be: the Japanese learned it
from Deming.) The quality of Japanese products shows no evidence of your
hypothetical obsessed-with-process-not-fixing-errors problem: Japanese
products continue to set the standard for high quality. Other countries have
market share too; do you claim they use a different quality process?

>> Consistency does not equal quality.

That's 100% wrong. (Are you unaware of that or are you simply debating?)
Here's half a dozen URLs pointing to definitions of quality in various
fields, mostly high tech, in which consistency is primary or prominent:

GNU software:
Web site design:
Web page design:
Video closed captioning:
Digital imaging:

Consistency is a fundamental quality attribute; all definitions of quality
include it directly or list it as the first corollary. Would you prefer a car
that consistently starts, or not? A document that consistently spells terms,
or not? A gun that consistently fires, or not? A table of database columns
that's consistently correct, or not? A doctor who consistently diagnoses
correct ailments, or not? Even a cheap product has quality if it's at least
consistent; even an expensive product loaded with doodads is of poor quality
if it's inconsistent.

You should notice consistency even in one document (internal consistency);
when you run a group, or a business, you should notice consistency from
document to document or project to project.

>> Moreover, consistency rarely leads to ingenuity.
>> And in the high-tech markets, ingenuity is critical to market success.
>> This is particularly true of software companies
>> (where many of us work).

So do I. No one is preventing you from achieving your goals in an innovative
way. But innovation is not an excuse for poor work. There is no such thing as
innovative accuracy--a statement is either right or wrong. There is no such
thing as innovative spelling--you either spell the words right, or you don't.
There is no such thing as innovative scheduling--you either finish on time,
or you don't. The argument that consistency or process somehow gets in the
way of innovation is a false dilemma.

>> IBM is NOTORIOUS for being a process obsessed monstrosity. And when was the
>> last time IBM had a huge software hit. IBM makes the grand, whopping
>> of their income in consulting. Handing out advice to people who,
>> think its important.

Humphrey is no longer at IBM, but you miss the point. He has more software
development experience than you, me, and 99% of all software managers. He is
showing them how to run their organizations as businesses, with greater
efficiency, predictability, and quality, and less expense, uncertainty, and
error. He is the leading authority in the field, and his results speak for
themselves, and I'm quite happy to cite him.

>> My preference is to have the individuals analyze their own work and ask
>> themselves "how can I do my job, and fulfill the organization's objectives
>> better?" This is what professionals do. They are on a constant continuum of
>> self-improvement.

Please, Andrew. The same individuals who are 100% at fault for errors, and
99.9% ignorant of the subject matter? We've all seen your rants and we all
know your professed opinion of individuals. Blow smoke up someone else's rear

>> Your preference is to perform some rigid analysis of the system. And design
>> more processes and procedures to rule out the chance for error. This is
>> bureaucrats do. They are on a constant continuum of organizing things and
>> striving for some zero-friction cycle.

"Bureaucrat"? You cut me to the quick. As a writer, I'm simply trying to do
the best work I can, as efficiently as I can, for my readers; in that
context, "best" does not mean good one time, poor the next. As a manager, I'm
interested in getting the best documents out to readers, as cheaply as
possible for my clients; in that context, "best" does not mean one writer
does great work, another poor.

Now, I didn't mean to suggest that if you only write one document, or you're
a sole writer, that you should go through a root-cause analysis. There are
more efficient ways to learn how to do better work. (I recommend STC for
that.) But as soon as you have more than one writer, or more than one
project, you might start to benefit; and once you get to the 50
documents/year level, you will definitely benefit.

Purchase RoboHelp X3 in April and receive a $100 mail-in
rebate, plus FREE RoboScreenCapture and WebHelp Merge Module.
Order here:

Help celebrate TECHWR-L's 10th Anniversary starting this month!
Check out the contests at
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 for more resources and info.

Previous by Author: RE: Who cares about ethics? (competition entries)
Next by Author: Re: YOU are responsible, even when YOU are not to blame (long)
Previous by Thread: Re: YOU are responsible, even when YOU are not to blame (long)
Next by Thread: Re: YOU are responsible, even when YOU are not to blame (long)

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

Sponsored Ads

Sponsored Ads