An Interview with Watts Humphrey, Part 23: IBM Tool Development, the Academic Advisory Board, and the Speak Out Article
This interview was provided courtesy of the Computer History Museum.
Using the PSP
Humphrey: [The PSP] was going along fine, but one of the things that hit me immediately was: how does it work on your project? I discovered people weren’t using it on the job. They finished the PSP course, they were all excited about it, it worked for them, but they didn’t use it on the job. I was wondering, “Well, heck, this improves the way you work. Why don’t you use it?” And the reaction I typically got was, “I can’t.” And I concluded the reason they couldn’t was that their managers weren’t supporting it, the manager pushed them to get into test. It wasn’t something they were supposed to do. All this measurement stuff, what do you need that for?
And so all of the
stuff we were doing, the quality stuff they would use, we didn’t have tool
support for it. Lots and lots of issues. Jim Over was
putting together some early tools to support the PSP course, which was helpful.
It was great. We probably couldn’t have done it without that. But he based them
on Excel and it worked fine, but it wasn’t connected into the environment and a
whole lot of stuff like that. So people weren’t able to use it. Basically
working alone doing disciplined work by yourself
without any support is very difficult. I was just able to do it because I was
committed and I didn’t have business pressures on me. But that was it. So
before I move on to the TSP and vision for the future, let me step back to the
IBM Tool Development
Humphrey: When I was at IBM -- this is again in my process job -- I was in charge of the tool work. We had tool development work in all the labs and a bunch of things came up which were fascinating. We had this steering committee. I remember Bob Balzer and I remember Lee Osterweil, and they’d review our stuff. We had central funding for the software tool development for the company. I had the funds, and we’d basically dole them out, and what we were looking at was the payoff. And we did some studies on that and found that basically none of the tools brought productivity or quality up more than 5% to 10%. You weren’t getting big improvements with any tools, and so one of the key things we were hitting was how do you improve quality? Just using tools wouldn’t do it. They wouldn’t improve quality and productivity and all that kind of stuff. And so we concluded the proposal was that you ought to be using design languages.
So instead of just
writing stuff you ought to be using a pseudocode-like
language that was much more abbreviated. It was easy and quick to write, and
the proposal was that we ought to base it on
I remember the group
in Boeblingen in
They put together a list of standard parts and they basically discovered that they needed essentially support engineers in various labs to support this stuff. After a while, when I was at SEI, I was over there and visited them in Boeblingen, and they had quite a few parts out there. It was doing quite a job. They had a fair amount of code in use, and they hadn’t had a single defect reported in all this code they’d shipped. They had used a very careful design language, careful reviews and inspections, so they were able to produce high volume code without error and it was very impressive.
And so I was convinced that it was possible to get very high quality code that used really good practices. I don’t think it lasted, and of course the whole object-oriented design and programming has really basically replaced a lot of that.
The Academic Advisory Board
Humphrey: Great. When I was at IBM, my last job, I ran the software quality and process group. And I think I mentioned that I set up an advisory board to come in and advise us on a lot of the stuff we were doing. I wanted some academics, and I wasn’t quite sure who to get. And so I got a hold of a guy in our federal systems division. His name was Neil Eastman. I had heard that he had contacts and he would have some good ideas. So I got a hold of Neil and got to know him, and he recommended that we get three professors, particularly Bob Balzer and Lee Osterweil and another gentlemen whose name I’ve forgotten.
And so we brought them in as an advisory group, and they weren’t people who were going to tell us what to do, but they were people I wanted to have essentially review what we were doing, comment on it, ask pricing questions, hold periodic reviews with them, advisory board meetings, and just kind of stimulate the IBM folks. I had found -- and it’s true not just in IBM but true just about everywhere -- that people get tunnel vision. They’re sort of there. And one of the issues we ran into at IBM -- and I see it in many other companies -- IBM was big enough and we had somebody somewhere in the company who you could identify as a leading expert on a subject and you didn’t need to go outside the company to find anything.
And as a consequence you get this very inbred behavior that you begin to think there’s nothing else in the world except what we’re doing in our company. And that I knew wasn’t true having worked elsewhere. And so Neil was very helpful and we set up this committee. Neil wasn’t on it but we had some other people on it. And it turned out coincidentally Neil Eastman ended up being the chairman of a committee for the Department of Defense to figure out what to do about software. And they recommended that a software engineering institute be established. And so Neil was sort of behind that. So I knew Neil earlier than that. It was a sort of interesting connection. And so I’ve got a copy of the Eastman report here somewhere in my file. But that was what started the whole thing off.
The Speak Out Article
Now that report-- well let me make another comment. Before I joined the SEI I was still at IBM. I was on the editorial board of the IEEE Spectrum magazine. And one of the things we decided to initiate was a column called “Speak Out.” I wrote one of the first Speak Outs. And it was in response to the issues you may recall back in those days. Reagan was in place, and they wanted to put this program together called SDI, popularly called Star Wars. And there was this big flap about it. Dave Parnas, for instance, had argued that it couldn’t be programmed. And I disagreed with that, and this was a column about why I disagreed.
Booch: If I recall, Dave was invited to be on some advisory council for Star Wars, and after he got into it he wrote a fairly strong letter saying, “I resign because what you guys are doing,” and I’m paraphrasing, “you can’t do.” And he went on. So you wrote this in reaction to that, in effect?
Booch: Great. That was a pretty dramatic time. I remember his message.
Humphrey: Oh yes. And so I
wrote it. What Dave had said was that you couldn’t program it. And I disagreed
violently with that. Later it turned out I was at a conference in
But the way he had ended up wording it was that you couldn’t program it. And so that got misinterpreted. And my contention in the Speak Out was that if he was talking about a quality problem, you can’t build high enough quality or high enough performance or good enough software to do the job, my position was if you could design the system and specify the software, we could build it. And so we ended up, I think, pretty much together. Marvelous guy, by the way. I don’t know if you know Dave?
Booch: Oh yes, he and I have had a number of conversations over the years.
Humphrey: Yes. Well, I was on the IEEE committee that was trying to decide what were the most significant contributions in the last 50 years, the contributors.
Humphrey: And we basically concluded there were two that were fundamentally different but they’re both very important and one was Dave Parnas. I was, in fact, deeply honored to be on that and able to participate in getting him named. It was just great.
Well, in any event
the Speak Out I wrote, I’ve got it here. I can fax it to you. You may want to
put it in. I don’t know if I’ve got an electronic copy but I would certainly
include it in the stuff I send to the history museum [
Booch: Absolutely. For the purpose of the interview, I think it’s sufficient to bookmark that it’s there and we can simply reference the physical copy that exists somewhere for it.
Humphrey: Right. It was IEEE Spectrum, April 1986.
Booch: Perfect citation.
Humphrey: Okay. So that’s that. Remember now, this in ’86 before I got to the SEI, before we did the CMM, PSP, or TSP, everything. I talked about many issues, and they were basically saying, you know you can’t build it because you can’t test it and all of this sort of thing. And I was talking about development discipline. I said the need was for a disciplined programming group. That’s basically what I was talking about, and I’m saying the development of disciplined programming groups involves several phases.
Initially, you must learn to manage costs and schedules, which begins with a strong commitment discipline and a rigorous estimating and scheduling process. The people who will do the work prepare their own estimates with the help of professional estimating groups, who provide formal documentation, et cetera. So I go through that. Then I say the next foundation is project control and I go through that. And then I say when initially applied these will produce rapid improvement. Of course, that’s what we did with the CMM. And then once schedules and costs are under control, you reach a plateau where you need to make major changes for further progress.
And now I get into quality and you need to learn how to manage quality and I go through that. And then I talk to do it properly you need to build personal disciplines, and then you need to build the team discipline. And what’s interesting is this document essentially describes what I’ve been doing for the last 23 years, which is kind of amazing. I was so surprised, my team was surprised. I pulled out a copy and gave it to them a few years ago. And we kind of looked it over and said, my Lord, that’s exactly what we’ve been doing ever since. So that was part of my outrageous commitment in 1986, my vision for what I wanted to do. And I was kind of surprised when I looked at that. But that was sort of the foundation, the description of what I intended to do.