Delusions of Quality
By Marie A Lenzi
Object Magazine June 1996
Another favorite story of mine is a conversation with a prospective
customer focused on quality development services... or at least I was.
The response from the prospect was, and I quote! "Mediocre is just
fine." (Could I make this up?) Needless to say, that ended that line
Recently, the issue of quality has been cropping up. I find this
curious because my course offerings have included quality measures for
8 years now and the are seldom requested... until lately.
I sense a familiar pattern. Simply, it's "learn it, then perfect it".
Kind of a first things first. I don't know if I agree with the
pattern, but if this is the case, it appears that we are getting
through the "learn it" portion of object technology and are
approaching the "do it well" phase. This, of course, surfaces the
question "what is well?"
Broad Quality Parameters
Typically, quality is defined as conformance to standards.
That may appear to be vague, but not necessarily. This notion of
standards can easily relate to what is valued by your organization.
Do you value completeness, correctness, consistency,
responsiveness...? Or do you value the budget? For this discussion,
let's define what we value as:
- Completeness of product, that is, all user-requested
functionality is present.
- Correctness of product, all user-requested functionality
is performed accurately, product doesn't crash.
- Consistency of product both externally and internally.
Externally for usability, internally for maintainability,
and ultimately, flexibility.
Object Technology and Quality
It is quite clear that the touted benefits of object technology are
strongly entrenched in issues of quality. Quality of process, quality
of product, quality of people, quality of management and leadership.
It is also quite clear that, like all things, if quality is not
actively addressed, you don't get any. The data Jesuits claim
"model the data and everything else will just fall out". Yeah, right!
In the same way, quality does not just happen -- you have to do it
Quality of Process
In too many cases, quality of process means getting one. More than
80% of American development organizations have a SEI Process Maturity
level of 1 (initial), euphemistically referred to as chaos.
The presence and maturity of the process have a direct and driving
bearing on most other tangible quality elements. Improved quality of
product completeness, correctness, or consistency cannot be expected
without some maturation of the process. In fact, improved product
quality can be directly traced to an improvement in the Process
Maturity level. Improvements in the Process Maturity do not have to
be traumatic. Small incremental steps are recommended, which means as
slowly or as quickly as you can tolerate.
Improvements in the development process are also easier to sell to the
nontechnical segment of your organization. Those outside the
technology space understand process, that is if there is none, then
there are quality and delivery problems. Addressing the process with
business types is a productive effort. Including them in the process
may require negotiation and leadership skills.
Quality of Product
Zero defect is the buzz word. Defects are manifest in two ways;
either the software fails to function, as in it crashes, stalls, or
otherwise hangs the machine, or more perilously, a business function
executes incorrectly. Software that hangs up the system is fairly
easy to detect and hopefully to repair, although sometimes not (where
is that leak?). It's the defective business functionality that can
really get you. Suppose you have an inventory control system with a
little hole in it...say, a little audit step that has been missed.
Suppose tuxedoes are slipping out this little hole into the back of a
Another business issue we are more aware of today is old, broken
business process. We can implement a piece of business functionality
precisely as specified by the user. The user can test, verify, and
sign off on the functionality, but it still can be inherently WRONG
strictly from a business process point of view. This is where active,
accountable participation by the business user in the development
process comes into play. Getting so analytically close to business
functionality frequently forces the snakes out from under the rocks.
Then when it is clear there is a problem, the right people can step in
before it's carved in electrons.
Quality of People
Now for the tough part. Process and product are tangible and
impersonal and, to some extent, mechanical. The sensitive, difficult,
and illusive topics are those of people.
Match task with capacity. Are your people doing the jobs for which
they are best suited? Do the have the necessary interest, talent,
skill, and training to deliver a quality performance? If so, you
typically get a high quality performance. (Everyone has "bad hair
days.") If not, you are not getting a quality performance. Train
them or change them.
Match task with enthusiasm. Do the people doing the jobs care? If
so, you typically get a high quality performance, ("Bad hair days" not
withstanding.) If not, why not? If they are apathetic and/or
slothful, you can fix this too. Unfortunately, most of this is not
self correcting. However, as a good manager and as a leader, you are
typically in a position to correct these situations. Active measures
must be taken.
Do You Really Value Quality?
The Malcom Baldridge Award has made many acutely aware of quality.
However, I have seen too many of these awarded in places where I have
direct experience with a severe lack of quality, at least by my
standards. Do organizations merely pay lip service to quality? Is it
just a lot of posturing? In many cases, I think the answer is YES to
both of these questions. Phil Crosby declared the "Quality is free."
However, I've always had a tough time with this. There is another
aphorism. Of GOOD, CHEAP, and FAST, pick 2, only 2. Pragmatically,
quality is not free. It takes time/money to build quality into a
process and a product. It takes money and motivators to attract and
keep quality people and to repair those not performing at the peak of
quality. Ever hear, "We'll test until the delivery date." So much
for quality. What happens to the process or to peer reviews when the
delivery date starts to slip? Where do the architecture and
specifications go when the user wolf is at the developer's door?
Don't tell me "we'll fix it after deployment."
In too many cases, the delivery of software, no matter what the
condition, is valued over the delivery of complete, correct, and
consistent, ie quality software. In my opening story, the prospect
was looking for a cheap labor. He didn't want to have to pay for a
talented and skilled person. He valued his budget over quality. But
this raises the question, "Have you budgeted for quality?" Has the
customer bullied and intimidated you into a price that precludes the
development of a quality product? I have to believe that the people
doing the work want to deliver a quality product. The opposite would
imply abject disdain for the customer. I have to believe that a
portion of substandard quality falls into the lap of the customer. I
want/need it NOW, or this is all I will pay, or here's what I want,
don't bother me again until it's finished. Something has to give.
Apply too much pressure and an explosion is imminent. Open a valve
and the threat subsides. The GOOD, CHEAP, FAST thing keeps coming
back. Quality has to be built in from the absolute beginning. You
can't patch it in later. It takes direct effort to achieve it.
Either do it or not, but decide up font. The point remains. This
quality thing is iffy and, in many cases, may be contradictory to what
is truly valued.
Thu Nov 13 15:57:47 2003