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 of discussion.

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 deliberately.

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 waiting truck?

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.