Home > Articles > Programming

An Interview with Watts Humphrey, Part 17: Measuring and Improving Software Quality

  • Print
  • + Share This
In this transcript of an oral history, Grady Booch interviews SEI Fellow Watts Humphrey. In Part 17, they discuss steps that Humphrey oversaw at IBM to measure and improve software quality.

This interview was provided courtesy of the Computer History Museum.

See the entire interview.

From the author of

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 Poughkeepsie. And they worked for a week or two to figure out the right way to measure software quality. They had a debate with really top flight people from all the laboratories, and they could not agree. So you'd think it was a dead loss, but I had a very good crew. So when the meetings were over and they basically didn't have anything, they said, “We think we know how to do it.” I said, “Okay, let's put together a proposal, a proposed CI-105 quality measure.” So they did. And we put together a pretty good one. I don't know if you want me telling you what it was?

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 Poughkeepsie lab. The director of the software lab or manager of the software lab in Poughkeepsie would not buy it. Basically, when I went out, I issued it to them, and I said, “Either come back and agree to do it, or come back with your proposal for what we should do.”

And so basically, most of them reluctantly said nothing, or they said, “Okay, we'll do it.” But Poughkeepsie came back and said, “No. We're not going to do it and we don't think it should be done.” I said, “Okay.” I called Jack Kuehler, who was then president of the IBM company. I said, “Jack, I'd like to have a meeting with you next Thursday.” He said, “On what?” so I told him. He said, “You bet. Bring them on.” So I called the lab director and I said, “We've got a meeting with Jack Kuehler next Thursday.” He said, “Oh, what on?” I said, “On CI-105, and you're going to tell him why you don’t think we should measure software quality.” He gulped and bought it. So we got the measures in place. We never had to go to Jack at all. I called him back and said, “Thanks.”

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 Kingston that had been enormously successful.

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 Watts agreed wasn't enough. And so thereafter, any time I sneezed about quality, everybody paid attention, because they know if I disagreed, everybody would call off their approvals, and it wasn't just a matter of getting me in agreement any more.

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 San Francisco, I think it was. It's a group that IBM had bought. IBM had started going into all kinds of miscellaneous stuff, looking for ways to grow. They had a satellite system they were going to put in place, and they had the Prodigy system.

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 San Francisco, and they made these programmable machines, and they had a lot of software in them. So I'd been asked to go out and look at it. They were having quality problems with this system. They had about 1,600 modules of code, a pretty good-sized programming system, about half a million lines of code.

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.

  • + Share This
  • 🔖 Save To Your Account