An Interview with Watts Humphrey, Part 17: Measuring and Improving Software Quality
This interview was provided courtesy of the Computer History Museum.
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Measuring Software Quality
Humphrey: What had happened
just before I’d gotten the job, one of the division presidents had been pumped
up by his software guys to give a story to corporate management, -- which was
the president, CEO and others, -- about how CI-105 [Corporate Instruction 105,
which required that each new product have better quality than its predecessor IBM
products and the best competitors’ products] could not apply to software. And
so he'd gone in and made this story. I think Opel was the CEO at the time. He
made this presentation, and Opel and Kuehler
basically looked at him and said, “No, you're wrong. It applies.” And the
division president was replaced within 30 days. That got a lot of attention,
and that's when I got the job. And so a big part of my job at the very
beginning was putting in place CI-105 for software. So I had some very good
guys, and Bill Florak was working for me at the time.
They had a quality
report, which we got, which had maintenance data, but they had a whole bunch of
other things too. The report they were putting out monthly they were shipping
to the labs. We had a lot of data, but I didn't know what the report was for. So
the guys came to me one day with this report for me to sign, because I had to
sign it every month. And I'd read through it, and I didn't know how anybody in
the lab would use it or what it would be for. So I asked. They said, “Oh,
everybody needs it. They've got to have it.” So I said, “Oh, okay.” So when I
went out and did a lot of lab reviews on quality and what they were doing, I
asked about this report and what they did with it. And so every month when they
got the report, they put together a staff group to go through it and figure out
what was wrong with it and argue with it. That's all they did with it.
It was just basically
a source of debate, and so they basically would come back and argue with the
staff about how they found errors in it and stuff. So when I got back and they
brought me the next report, I said, “I want to make one change.” They said,
“What's that?” And I said, “I want you to put right here, 'This report will now
be quarterly.'” They said, “Oh, you can't do that. There'll be all kinds of
problems.” I said, “Well, do it, and let's see what happens.” So they did. No
flap at all. No one objected particularly, but they still were going through
the recycle. So after two quarters, when they brought it in for me to sign, I
said, “I want to make one change.” They said, “What's that?” I said, “This is
the last report.” So we shut her down, and it didn't cause a ripple.
So software quality
was being addressed in a rather superficial bunch of ways. We had to figure out
how we could really measure quality of software. So we called together people
from a bunch of the labs, put together a working group -- technical guys -- led
by Bill Florak and his team in
Improving Software Quality
Humphrey:
Okay. Well, basically, it was focused on the defects, the number of defects
found in the first six months of installation of a product, and the number
found during the first five years, product Y. The number found in the first six
months had to be fewer than the previous version. We had all kinds of problems
in terms of installation rates and everything, and so people had to make plans
based on history. They had to project out what they expected in terms of
numbers, and then measure against their plans and all that sort of stuff. But
they put together a series of measures. It was a cumulative defect report, is
what it was. Everybody objected to it. I sent it out to the labs. A number of
them were kind of reluctant, so we talked to them and bent a lot of arms. I
basically got most of the people to buy it, except the
And so basically,
most of them reluctantly said nothing, or they said, “Okay, we'll do it.” But
We put it in place,
and we had it in place for two or three years before I retired. We cut the
number of defects like about 50 percent a year on the measured programs. It was
just extraordinary. People learned an enormous amount. They learned the rates
at which people installed. They learned the rates at which errors happened. I
don't know how they did it. Basically, it was all intuitive. No one had a whole
lot of data. We did learn one thing. I can remember one product, and we did
learn a whole lot.
Ron Radice looked at some data and figured out that most of the
defects clustered. The defects in big systems cluster in a limited number of
defective modules. And if you really want to focus on improvement, the thing to
do is to identify those modules by gathering data as you're testing it, and
then thoroughly inspect the defective modules and clean them up, following
Fagan's inspection methods. And Ron used it on some products in
By the way, in the quality
and process job, I had studiously stayed out of the announcement cycle. So
they'd actually been reviewing every product announcement, and there was an
enormous amount of busy work, just looking at every announcement and getting
involved in announcement reviews. I concluded that there was no particular
advantage to us. There were lots of guys involved, so I stayed out of it. I
basically said, “We're not going to be involved. Take me off the approval list.
You just go through quality assurance and the other guys can do it. You don't
need my approval.” So they did. And on one product, it actually had been
subcontracted out and then brought in for testing. I think it was an MVS
product. Our guys came in and said, “This is a dog. You literally can't let it
go. It has nine defects per KLOC (thousand lines of code). It's going to be a
zoo. It'll be a real failure in the marketplace. So you've really got to stop
it.”
So we went and got
hold of the product manager and talked to him. I told him the technique, which
actually identified the defective modules in this thing. He said, “No, we don't
have time. We've got approval. We're going to go.”
So I said, “Okay. I
don't agree.” So I put a note to that effect, copied the quality assurance
people, the service people, the marketing people, everybody else. “We believe
that your product is defective and should not be shipped at this point.” And so all the concurrences that this guy had previously had were
withdrawn. All of a sudden, nobody agreed that he should ship the
product and he had to come to me. I said, “Here's what you do,” and I had him
go back and follow the Radice method. I said, “I bet
you'll bring it way down. I suspect on that product you'll find at least 300
defects.” He said, “Oh, no, no, no. Not a chance.” So they did it and they got
past 400.
It was amazing. So
they finally got it, they were all done. The product was really pretty damn
good, and I finally agreed. Then they played bloody hell getting all their
approvals from everybody else back. It took them months to get the service
people and the quality assurance people and the marketing people all back in
the boat. Just telling them
The Amdahl Story
So it was easier to
work with me, because I could tell them exactly what to do. As it turned out, I
got enormous power out of that, which I had not expected, but it was really
quite effective. We had the CI-105 stuff in place, and it really worked
extremely well.
I later went out to
review a lab we had in
That reminds me, let me tell you about Prodigy. I really didn't get
involved much in the satellite thing, although it was a real hot button of Bob
Evans’, but it really was never a particularly good business. But they did
actually get into that business. But they'd also bought this company that was
in telephone switchboards. This was a little company, out in
Booch:
In what language was this?
Humphrey:
I don't remember. It was very likely C or something like that. I don't know. It
wasn't IBM traditional stuff. But they shipped the product, like two or three
years before, and their maintenance costs, the defects they were getting, were
just out of sight. They were spending a bundle on it. So the head of the
operation asked me out there to review it and give him some advice.
And so we did, we
went over it. And the first thing I said was, “What data have you got?” They
said, “We don't have any. What kind of data do you mean?” I said, “I want to
know the defect data, error data, anything like that.” “Oh, we don't have any
of that.” Well, it turned out they did. As some engineers had gathered some of
this data, they had data on the modules and how big they were. So we had them
put together the data. It was sort of a flank speed effort to get this stuff
together and look at the 1,600 modules. What we found was that 3 percent of the
modules had over 50 percent of the defects. I think it was-- yeah, 3 percent
had 50 percent.
I believe something
like 86 percent of the modules had had no defects in three years. So 14 percent
of the modules had all the defects, and 3 percent had half of them. So I said,
“What you want to do?” and so they did. They decided to go do it. That's what
they did. It was amazing. It really did clean up their costs dramatically. I
didn't stay long enough to find out exactly what happened, but I'm sure it made
a big difference. While I was there, however, one of the ladies, who was one of
the engineers there -- I don't know, she was a manager or something -- was
Naomi Trapnell. She turned out to be Fritz Trapnell's wife. Remember Fritz who used to run OS/360 for
me?
Booch:
Yes.
Humphrey:
He had left IBM from the Hursley lab, and later
joined Amdahl Corporation as their director of programming. He was now the
director of programming for Amdahl. Naomi invited me to come over and have
dinner with them. I said, “That's great.” So I did. We weren't going to talk
business at all. There was nothing anti-competitive about it. So I went over
and we had a lovely dinner, and Fritz at one point said, “What in the world did
you do to quality?” “What do you mean?” He said, “Starting about a year ago,
our customers started to tell us that the quality of IBM's
programs have gotten dramatically better.” That was CI-105. My reaction
was, “When the competitors start to praise the quality of your products, you're
doing the right stuff.” It really made a hell of a difference. So I had a nice
chat with him.
Booch:
Did you tell him much about what was going on?
Humphrey:
No, I didn't tell him. I just told him the objectives, the quality had to be
better than its predecessor, but not any of the mechanics or the measurements,
or anything like that. That was our secret, so I couldn't tell him that.