This interview was provided courtesy of the Computer History Museum.
Moving to the SEI
Humphrey: So moving on from that, I went to the SEI from IBM. And I told you about Eric Bloch and that sort of thing. The guy that was the first director of the SEI was named John Manley. A very nice guy. I thoroughly enjoyed him. We had a wonderful dinner with him and his wife when I was being interviewed. And so I liked John. I didn’t know him a lot because he left before I got there, but he wasn’t a good fit for the job. But he was a very nice guy, and we had a wonderful understanding before I got there.
Booch: Not a good fit in terms of just managerial issues, or technical leadership or …
Humphrey: Yes, somehow managing the technologists and that sort of thing. He didn’t -- they didn’t work. They generated sparks.
Booch: Do you recall how big the SEI was at the time you joined them?
Humphrey: It was quite small.
When I first got there I think Larry Druffel was
running the search committee. We set up sort of an acting director. I’m not
sure whether it was Nico Haberman
or Angel Jordan, but they were temporarily acting as director for a very brief
period before Larry Druffel. And Larry Druffel took over very shortly after I got there. One of
the problems Larry had was they didn’t have much of an administrative
operation. We were in a special building over on
Booch: Right. As I recall, the gentleman that had hired you -- he was out the door about the time you got there.
Humphrey: Yes. So I arrived
there with a totally undefined portfolio. And they asked me if I would take a
secretary who was the ex-director’s secretary -- John Manley’s secretary -- a
lovely lady. And they didn’t have any place to put her. And so I arrived, I had
nobody working for me. This is the first time I had had nobody working for me since
college and it was a marvelous feeling. All of a sudden, I wasn’t administering
anything. And so I was able to start thinking and putting together my own
ideas. Well, that didn’t last very long because Larry right away needed somehow
to pull together an awful lot of pieces -- the administrative parts -- finance
of the SEI. And he asked me if I’d run that. And I told him I would temporarily
do it on two conditions. One: it was temporary, I’d be working out of that. We’d
get somebody in those jobs quickly. And second: I could then form my own
process department. And so he bought that. And so fortunately, I was now in the
position of setting up and distributing funds, laying out budgets, running the
whole group, getting this place going. And I guess I
basically was able to ensure that we had a properly funded process group. So
that was a nice dividend out of that. And this is while I was going ahead and
starting with Bill Sweet, and we were starting on the CMM thing I had mentioned
before with the folks up at MITRE in
Booch: What a wonderful lady she is. Where was Dave Garland around this time too?
Humphrey: I didn’t see Dave. Dave wasn’t there. He wasn’t there at the Institute; at least if he was I didn’t have any interaction with him. But I remember Mary, and I would just have lots of debates -- kind of informal discussions -- and we were on a totally different wavelength. I mean the process that she did not view as any kind of rational science or knowledge. She was interested in stuff that was sort of hard knowledge. And so we had lots of debates about that. And at one point I don’t know if she proposed it or I did, but she was having a lot of trouble getting her work done because people constantly wanted to come meet with her.
So she and I established a schedule where we would have one or two afternoons a week where Mary Shaw and Watts Humphrey were meeting. Period. And we could not be interrupted. And we were meeting by ourselves. We weren’t together, but both of our calendars were blocked. And so we were both able to get lots of work done that way -- it was marvelous. My Mary Shaw meetings were very productive. I thoroughly enjoyed Mary, although we disagreed on a lot of stuff. Another thing that happened in there was quite early. I remember, I read an article in Business Week magazine. I think this could very well have been in ’86 or ’87, but the records would show. I don’t remember the date. Remember the Ashton-Tate company?
Booch: Yes, I do. They were one of the early PC companies. Absolutely.
The Ashton-Tate Story
Humphrey: What’s interesting is Ashton-Tate, I think, was second in size to, I don’t know -- Microsoft or somebody -- but it was one of the big three companies to the software business. And it had this dBASE I program, which had really been an enormous success. And they then announced a dBASE IV to replace it, upgrade it, to compete with Oracle and others to stay in business. This Business Week article was about the problems they were having with dBASE IV, because when they developed dBASE IV it was running late, all kinds of problems for them, they weren’t able to get it out of test. So instead of finishing test, they stopped the test, which is a normal way they do it in a lot of places. And of course, how do you know when you’re finished testing? You don’t, which is one of the fundamental problems. But in any event they stopped testing and shipped it. And the basic position was ”we’ll fix it later.” Well, it turned out with the database system they had a number of defects that were actually destroying people’s databases. That’s not something you can tolerate. And so they rather quickly ran into serious problems. They had to pull the program and go rebuild it to reship it. And this was going on when I read this Business Week article, and they had no idea when they’d get done. They were under enormous pressure, all kinds of things. So I called the executive offices of Ashton-Tate and asked to talk to the assistant of the CEO.
Booch: And their CEO at the time I think was George Tate, was it not?
Humphrey: No, it was Ed Esber. Basically, I
told him that I had a strategy I think would help him them accelerate getting
this thing out the door, and I’d be happy to come talk to him about it. I asked
them to pay my airfare, which they agreed. So I flew out. I’ve forgotten where
their office was. It was probably
Humphrey: Is that near
Booch: Yes, it is.
Humphrey: So there was one executive who couldn’t make it. Guess who that was? The development VP. Of course, he didn’t show up. So we talked briefly about what they were doing and their status, and I described the strategy that we had worked out that had been enormously successful. And Ed thought that sounded very interesting. So how long will it take? This is like in October. And I said it’ll take about three months. It’ll take about a month to get a team of people really trained to do good inspections. You’ve got to get some data on your testing. Then you’ve got to take probably a couple of months to go through at least the 10 percent of your worst modules, inspect them and fix them, and then you can probably get the quality pretty well fixed up. I would guess it would probably be January or February. And Ed’s reaction was, “We can’t do it. We’ve got to ship in November.” And I said, “You won’t ship in November unless you do something like this.” He said, “Oh no, no, we’re going to ship in November and that’s what everybody says, et cetera, et cetera.” So they said no. Well, as you know they didn’t ship in November. They didn’t ship the following April, and they went out of business the following spring. And I see that message all of the time. “What has to be will be” is sort of the feeling and it wasn’t. It just didn’t happen, period. And so it was a real frustration for me how hard it was to get people to actually buy the kind of stuff that they have to, to do the job right.
Booch: So I’m hearing you say that a common theme you’re seeing is that people are happy to do it wrong and invest the time to fix it, which sometimes never works, as opposed to investing the time to get it right the first time.
Humphrey: Well, it’s not even quite like that. What it means is they have this optimistic feeling that they can fix it. Like these people, the view -- and I see this at Microsoft, in particular, and other companies, too -- “if we could just get the right tool we can do it.” For instance, in the security business, I see that all of the time, the buffer overflows. The security problems on the Internet, over 95 percent of them are due to standard garden variety defects in the code. It’s amazing. A lot of them are defects that most programmers won’t recognize. A lot of them can’t identify what a buffer overflow potential is. But Microsoft has a wonderful tool for identifying buffer overflows and going through and making sure they don’t cause a problem with the system and identifying them so you can fix them.
So when I talked to some people there that had a little data about that tool they had I said, well what percentage of the problems does it find? About 20 percent. I mean, you’re going to hang your life on something that finds 20 percent of the problems? So that’s what we’re doing. People aren’t really looking at the data. They don’t understand it. They’re not looking at it scientifically. And that I think is a serious problem. So I ran into that with those guys too. They wouldn’t listen to the facts. They couldn’t believe them. They would rather believe their own mythology than focus on what reality really is. And that’s basically, I think, what the whole community has been doing. We’re not facing reality. Reality says testing forever won’t produce quality products -- we know that. We know that for every other technological field but we still struggle with that with software, and that’s where the whole academic community is saying “We can improve testing.” There was a big report to the president on what we had to do with software quality problems. It was all about that. More testing. Better testing. It’s insane. In any event, I’ll get off that soapbox again for a while.