An Interview with Watts Humphrey, Part 21: The Personal Software Process
This interview was provided courtesy of the Computer History Museum.
The PSP Research
Humphrey: I decided that what I would do would be to try applying the CMM principles to my personal work,and so I did. I tried to use it on balancing checkbooks, putting together simple processes, and that didn’t tell me anything. So I decided I’d better write some programs. I hadn’t programmed in years, but I was still running the process program at the SEI, and I decided I would start writing Pascal programs because I hadn’t written anything in a long time. And so I started doing that, and I was asking the guys at work for help and then getting some guidance because they were a lot more recent programmers than I was.
And so that’s how I
started the PSP [Personal Software Process] and it was extraordinary. I wrote a
few programs. I had just gotten started and Larry Druffel
called me in one day -- he was thinking of making me a fellow -- and I said,
“Well, what would that mean?” I had retired from IBM. My mother was living in
So it was an amazing
family connection. But in any event, they were living in
So I went to talk to Larry Druffel about it and he said, “Well, we could make you a Fellow.” And I said, “What’s that mean?” He said, “That means you can work on what you want to work on where you want to work.” And I said, “And you’ll pay me, too?” And he said, “Oh yeah,” and I said, “That sounds pretty good to me.” So I agreed and he set up a whole Fellow structure and everything else, and it went through a procedure and a committee and they made me a Fellow. And so I got myself replaced. I got Bill Curtis to come take my process job, and I decided to come down here and work on the PSP. The CMM was going already. I wasn’t really that deeply involved. I was concerned with it because it wasn’t really nailed down and I wanted to make sure it didn’t go off course, but they were doing their own thing. I got busy doing the PSP, so that’s what I did.
Booch: Back to Bill Curtis, it’s
interesting that his name came up here because he had been involved in --
wasn’t there some semiconductor consortium down in
Humphrey: Yes, the MCC.
Booch: The MCC, yes, that’s where he came from.
Humphrey: He was down there. He worked for Les Belotti.
Booch: Yes, Les as well. All these names come back. Right.
Humphrey: He worked for Les Belotti down there in the MCC. I remember going to a meeting with him and visiting with him, and they had quite an interesting little group down there. They were doing great stuff, but they were having a real problem getting industry support -- particularly for the software -- and that stuff essentially wasn’t getting anywhere. And so Bill did come and replace me. I think it was about January ’90 I finally quit that job and came down here and, as I say, I wrote a total of something like 72 programs in Pascal, and then I moved to Object Pascal, and then I moved to C++.
They were all, kind of, statistical programs and, sort of, analysis programs -- stuff that wasn’t particularly useful for anybody -- but it was stuff that I was interested in and measuring things and stuff like that. So, kind of, programs I made up with little requirements, but I had a whole lot of practices I was trying to follow, and I pushed reuse and as a matter of fact, I made reuse libraries when I got into Object Pascal and then C++. So I built these big class libraries and I had all this reusable code. I got to where I was writing programs where something like 80% of the code was reused. It was enormously effective, and the thing that was most effective about it to me was several things.
I put in some practices for how I do it, but the quality results were extraordinary because I was using the PSP. I was measuring quality. I was managing it and by and large my programs would have zero or one or two defects in compiling and testing. I’d have practically no defects and the programs ran. I mean, I basically never had problems. My reusable programs, I’d just turn them on and I’d plug them in and they would work and it would be great.
So I could build and compose these great big systems without any real trouble, and I had a series of procedures for how you write reusable programs. And basically what I did, I had a user’s manual as the opening of the listing. I had instructions on how do you use the program, what are the calls and returns, what are they, and then there’s a series of warnings about things you can’t do and shouldn’t do, but that was basically it. And so these programs I discovered -- it was a dream. I was able to compose programs and stuff.
When I wrote the very first programs I decided that I was going to measure everything because I didn’t know what to measure, so I’ll measure everything. And so I decided to measure how much time it took me to do everything, how many defects I found and fixed at each step, how big everything was that I built, and it turned out that’s all I had to do. I measured that and that’s all the measures I needed, that’s all I could get basically. That’s what you do. First thing I discovered the minute I wanted to measure, though, I had to have a defined process because you can’t define a measure without having a process. What’s a defect? You got to know when you found it and when is defined by your process.
So basically when I wrote the first program, I was going to sit down and write it and I realized I couldn’t do this until I had a process, so I decided to put together a process. As I got developing the process for my very first program, I realized I’d made my first mistake. So I backed up again. So I next developed a process for developing a process. So that’s what I did first. I put together a very simple development process, and then I used that to develop my software process, and then I used that to develop my first program. If you remember, I told you that the way I learned to write programs was when I was inventing instruction sets. So I would actually go back and change the instruction sets when I was writing programs early on.
Well, I couldn’t do that with Pascal, but I could do it with a process. So I would write following the process, and then I realized that when I was finished with the process that I really didn’t like the way the process worked in these ways. I put in a little procedure for myself. It’s called a PIP, Process Improvement Proposal, and so I made a note as I was writing my programs of the things that were inconvenient about the process, and I tuned my process, and I kept doing that. I had a problem because if I tuned it too much, of course, my measurement system was screwed up because I couldn’t measure and track from program to program.
So I had a problem with compatibility there, and I had various versions I went through. And so I gathered data. I had data on every defect. I’ve got it all here. I’ve got all these programs. It was all done by hand. I didn’t have any tools to support me. I just had the regular compiler. So I gathered all this data by hand which was a real pain, but I found it didn’t take very long. I was quite surprised how little time it takes to track your time and defects and measure size of a program. I mean, it couldn’t have been more than 5% or 10% of my time, if that.