This interview was provided courtesy of the Computer History Museum.
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
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?
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.