An Interview with Watts Humphrey, Part 21: The Personal Software Process
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
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.