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.
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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
Booch:
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?
Humphrey: Correct.
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.
Booch: Yes.
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.