An Interview with Watts Humphrey, Part 36: Agile Methods, Open Source, and Cloud Computing
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
Agile Methods
Booch: I’d like to turn our discussion
to a couple of remaining topics. You’ve had such a vast and colorful history
here I’m curious as to your take on a few things that have been popping up in
the software space in the most recent years; in particular, your take on
extreme and agile programming, what you’re thinking about open source
development. I believe you have some opinions with regards to languages as
well. Can you comment on this?
Humphrey: Sure. Let me talk
first of all about agile programming. I actually went to Agile Universe a
number of years ago. They asked me to be a keynote speaker. And so I was there
and listened to a whole lot of talks, talked to a lot of people. And I have
just a very general reaction to a lot of the agile programming and the agile
movement. There’s some very positive elements to it. I
mean, it really is looking at not just coding, but it’s looking at teams and
how do you do programming. And so none of the other methods
have really done that. And so this is really thinking about the dynamics
of how teams do projects. And I think that’s very positive. And I think they’ve
done a lot in terms of applying discipline. People think about agile as sort of
something simple you can throw in, but if you really go through the methods
whether you go through SCRUM or XP or whatever, they’re disciplined methods. They’re
not just things people just go in and throw in something.
And the problem that
I was concerned about and I run into time after time,
is that people don’t use them in a disciplined way. They tend to sort of pick
up and use the parts they want. I mean, people say they’re using extreme
programming, and you really poke at it and you discover that they’re not really
doing re-factoring and they’re not really doing this or that, but they’re not
doing design work. And so that’s the part of extreme programming they picked up
on -- not doing design. And so it really isn’t a disciplined framework that people
use in that sense. Potentially if they did it right it would be. We, for
instance, had an issue with Intuit. They had a lot of SCRUM teams at Intuit. And
a study they did -- a fellow named Jim Sartain, by
the way, and he’s been a great supporter. He’s a great believer in data. And he
was the leader of the TSP effort at Intuit. And he subsequently left. He’s at
Adobe now. And he brought the TSP there as well. So they got a big effort.
But in any event they
were looking at the data on their SCRUM teams and how they were doing. And
based on everything that he could determine, the SCRUM team’s performance was
not as good as the non-SCRUM team performance. It’s nothing to do with TSP or
anything else. The SCRUM did not appear to be greatly improving the performance
of their teams, which kind of surprises me because I believe a lot of the agile
programming methods really do help. My only conclusion is that the Intuit
people probably had some pretty disciplined efforts already underway. And as a
consequence this was not a big plus. And I don’t know if you know, but Intuit
and the tax business, they have to have an annual cycle and a very tight plan,
so they really do manage pretty tightly to get the stuff out on schedule,
predictably because the world can’t wait for that. The tax stuff has got to be
there when it’s needed, period. And so they were doing pretty well and
apparently the SCRUM wasn’t helping. And so they brought in -- is it Ken Schwaber?
Booch: Yes.
Humphrey: They brought him in,
and he basically went through it and said that it was only about one or two of
the teams were really doing it right. So they started to focus on that. And in
parallel they started introducing the TSP. And it turned out that a lot of the
TSP teams had used SCRUM before and wanted to use it with the TSP. And so they
were using SCRUM and the TSP together. And there’s no reason you can’t. SCRUM
is basically an approach on how you do stuff. And the TSP gives you a whole
series of specific things you do behind it, the TSP launch works fine, all of
the measurements work fine, the quality management works fine. So there are a
few places where we’ve got some rough edges to make it fit but not a whole lot,
and that’s true of any of these Agile methods. And so
they don’t conflict with the TSP. One of the concerns I’ve got is that people
seem to see them as conflicting.
And that was one of the big problems I had
with the book
that Barry Boehm put out on discipline versus agility or something. And he
was basically putting us at extremes that you’re either using the PSP which is
a discipline extreme or using Agile which is the flexibility extreme and that’s
totally misleading. I mean, they’re not opposite extremes, they’re
complementary. And so I think there’s an awful lot of misleading stuff in the
field about how these things work. And my reaction is: the practices in the
software business are so bad today that any orderly method will improve things.
And I think the agile methods will do that and that’s fine. Unfortunately, they
don’t go as far as I believe they should to provide the real improvements we
need. And I think I told you before, the level we need to get to -- and it
isn’t instantly but it’s going to be not too far down the road -- we need to be
talking about a few defects per million lines of code. That’s a factor of a
thousand better than the quality we’re getting today. You don’t get that by
trying harder. That’s basically all of the stuff we’re talking about -- all of
these other methods are to use tools and bright people and have them try harder.
My contention is, that’s certainly great. Use the best people you can get. Use
the best tools you can get. I’ve got nothing against that. But you’ve got to
use a very disciplined framework. You’ve got to have
data. You’ve got to analyze it. And you’ve really got to work with and focus on
how you measure the performance of your process and how it works and the tools
and your people and what they do. And that way we can move forward. And with
the TSP we’ve gotten vastly better performance than I had ever expected. One of
the studies found that a third of the projects delivered products that had no
defects found by the users, period. Now, that’s a third of them. I mean, that’s
an enormous number. I think that’s probably not holding up now because the
early ones were all ones that we coached. We’re getting more and more that
other people are coaching and they don’t have quite the background we do and
all of that sort of thing. So the numbers aren’t quite as good. They’re a lot
better than average but not as good as our teams.
But nonetheless, the
programming community is a very sharp bunch of people, and they can do
extraordinary work. The thing that I like to say is that human performance is
unlimited. I look at one thing, I don’t know if you’ve ever looked at it, but
the time it takes to run a mile. I’ve got an Excel spreadsheet I can bring up. The
time it takes to run a mile, world record. In 1865 it was four and half
minutes. And they thought no one would ever run faster. Then in 1937 it was
4.07. Then in ’54 they broke the 4-minute mile. And in 2000-2009 it has gone
down to about 3.7 or something. I don’t have the latest numbers but it’s 3.7, 3-point-something minutes now. But if you take
that and make a linear regression projection of how fast a man is going to run
in the future, we will get to a 3-minute mile in 2116. And a two and a half
minute mile in 2200. Well I’m not sure we’ll ever do that. Linear regressions
are probably not likely to happen here but it’s extraordinary. But it’s been a
linear rate of improvement now for well over 150 years almost. It’s been
improving linearly all along. And it’s quite amazing. So
human performance is extraordinary.
Booch: So is your running a mile going
to fit on that list some place?
Humphrey: No. I’m off the
scale. But I will say if you compare that, and I did, with the Kentucky Derby,
the rate at which horses run. And Big Brown ran the Kentucky Derby in what was
it, 2.03, I think. Let me see if I got the time here. Yes, the time in minutes.
And yes, that was in 2008, 2.03 and what’s interesting is if you look at that
and you look at the curve for the Kentucky Derby for over 100 years, it’s flat.
I mean very slightly better but not much. I mean there is no measured
improvement. And they’ve got the advantage of breeding. They’ve got all of the
technology advances, everything else. And horses aren’t getting faster. And so
my point is the people are running faster, and it’s not that they’re running
faster because all of these other things are helping them, it’s because people
are learning how to improve themselves, the whole motivation, and the whole
improvement framework. People can just do extraordinary stuff. World records
are broken all of the time. And how can that be? This is a world record. It
stood for years. I don’t know if you remember Johnny Weissmuller…
Booch: He was the old Tarzan guy.
Humphrey: The old Tarzan. In
the early ‘30s I think he held every world record in swimming, just about. He
had a whole mess of medals. And he was basically beating the world. And at the
time shortly before he died in his 80s, he said that, “Today my world records
are routinely being beaten by high school girls.” I mean, that’s extraordinary.
And I was over giving a talk at Embry-Riddle, talking to the students and the
faculty there. And I was talking about human performance and improvement and
that sort of thing. And I told this story. I said, “Who here has heard of
Johnny Weissmuller?” and all of the faculty sort of
standing in the back all raised their hands. And one student in the middle
raised her hand, a young girl. And so after I finished my
talk one of the professors came up to me with this girl in tow. And she
was a little thing. I mean she wasn’t very big, a little over 5 feet tall. And he
said, “I’d like you to meet this girl” and so I did and I shook her hand and we
chatted briefly. And it turned out she was the first high school girl to break
Johnny Weissmuller’s world record in the butterfly. I looked at this woman.
Have you ever tried to swim the butterfly?
Booch: I have. It’s a terribly
difficult stroke.
Humphrey: That was
extraordinary. And so my reaction is that that’s just extraordinary. It’s just
beyond what you could ever expect. People can do amazing stuff. And frequently
they’re not aware of what they can do. So I think that’s one of the things that
I think is just-- I’m not quite sure how we got here. Were we on agile still?
Booch: We were on agile and I wanted to
turn then to the discussion of open source and what your thoughts are on it
are.
Open Source Programming
Humphrey: Well, open source, I
think is a fascinating trend. I was very interested in The Cathedral and the Bazaar and some of that as to what’s going
on. And it kind of amazed me that we’ve got so many people that are so talented
that are willing to actually contribute to essentially [the] public good. And
they’re very proud of their work. These are people who view themselves as
craftsmen or -women. And they’re proud of the quality of what they do. They
want to get it out there. They want people to look at it.
That’s what we need
in the software community. It’s the kind of performance that by being able to
motivate that I think it’s just an enormous advance. Now, the other side of it
is, it’s not clear to me how broad the open source movement can get. I think
there are areas where it makes a lot of sense, but I just can’t see somebody
getting an open source program to fix the problems I mentioned with this
company in
And to get continuing
revenue they’ve got to either have a service system where you get in touch with
us and we’ll fix your problems and that means you’ve got to have problems. And
we’ll give you upgrades. That means you’ve got to be making upgrades and all of that sort of stuff. And so people want to buy the
operating systems or get them to do a standard job on their computer. And by
and large, you and I, when we get an operating system, we don’t want the darn
thing to change. But the manufacturers and suppliers want to change it because
that’s how they get revenue. So they keep trying to come up with these added
little gimmicks and features that will make people want to buy it. And they’re
not terribly successful with that because, I mean if you noticed, what was the
new one,
Booch: Right.
Humphrey: Nobody moved to
Booch: I would have pegged you a
Macintosh guy.
Humphrey: No. I do have some
kids that are. I’ve got a daughter who’s an artist. She runs her own art and design
business and she uses both Macintosh and PC. A couple of the kids use Macintosh
but I used the PC originally. I had one of the very first PCs at IBM. I wanted
to get it. And I held off writing my Managing
for Innovation book until I got it. That was my book number two that I
wrote on the PC. The first one I did on a typewriter, a portable typewriter.
But I did that one on the PC. And of course the media and everything else on
that is so badly out of date, I don’t think I’ve even got the manuscript any
more. The media has changed so many times that it’s no longer compatible and
you can’t use it. It’s frustrating.
SEI was all Macs when
I got there. But I stuck with the PC, and they ended up moving to the PCs as
well. My sense is the whole operating system business is very likely to crater
out. The open source community, at least when you’ve got operating systems that
are available and that work and particularly when Neelie Kroes
in Europe is pushing them to begin to define interfaces and begin to nail stuff
down, they’re exposed just like IBM was to the plug-compatible competitor
business. And so I think the writing is on the wall, whether it’s five, ten or
twenty years, I don’t know. But the operating system business I don’t think is
going to be a viable business long-term.
Booch: Got it. So tell me what you
think about languages, in general, programming languages?
Computer Architecture
Humphrey: I was just going to
say before I move to that I’d like to talk also about computer architecture. Because
I think, quite frankly, the whole architecture of the computer and operating
system today really ought to be in microcode. Bring it all the way down so
you’ve got an interface that gets all the way out to the application
environment, the API. So I believe the operating system ought to be part of the
computer itself, and I think, quite frankly, the move to do that, they have to
actually change the nature of the architecture. Remember I mentioned that I designed
two computers when I was way back at
Booch: Yes.
Humphrey: One was UDOFT, and
the other was MOBIDIC. And UDOFT was a very creative machine. It had two
memories, one for instructions and one for the data. And I believe that’s where
we’re going. I believe we’re going to end up with architectures where the
operating system and all the stuff that provides virtual systems and protection
and security and all of that, is in separate memories and is totally
inaccessible to anybody through software, period. We’ve got to get an iron-clad
door, and people can’t get to it, period. Most users will use the API and stay
there comfortably, and you will have virtual machines and communicate between
them, and ways to move data around and all that kind of stuff. And the security
and the foundation of the system and its reliability and its recoverability and
all of that is completely protected from all the hackers and everybody else who
wanted to get in and take over our systems. And I think until we get there,
we’re not going to be safe. When we get there, and there’s no earthly reason we
can’t, but I don’t think we can afford to stay where we are now. The world is
just using software for way too much sensitive stuff, and the level of crime --
people stealing stuff, stealing identities -- people can come in and they can
dump sewage into rivers and all this kind of stuff remotely. It’s frightening.
Booch: This reminds me of something you
said in one of your “What’s New?” columns that I picked up on. You were basically
talking about what you think the future of the web is. I pulled it out, but it was something to the
effect that you really didn’t see the web becoming a place for pervasive
computation. So I’m just trying to get clarification on what you mean, because
the folks that are heading towards cloud computing and the like and software as
a service -- what’s your take on that? Because your comments in “What’s New”
seemed to say you don’t think that’s the way we should be going.
Humphrey: I actually worked with
people who were going to local systems where people had terminals on their own
systems, and they would be able to do it remotely and this sort of thing when I
was at IBM. So we were trying to build such systems where people would, instead
of having their own capability, they would have to depend on a central
installation. What I’ve found is people are willing to do that for some of
their stuff, but not everything. So I think there’s a range here, and that
cloud computing, I think it’s almost certainly got some opportunities. There
are people who don’t want to have a system installation and that sort of thing,
and I think that’s appropriate. There’s certainly nothing wrong with it.
But I can’t visualize
putting all my data on somebody’s cloud, and then all of the sudden having them
introduce a new incompatible something or other. Because our
field has been doing that. Every five years or so, something new happens
that’s incompatible and you have got to re-do it. When you start dealing with
databases, and we’re talking about people with terabytes of data, we have got
to have persistence of this stuff. We can’t tolerate moving to new,
incompatible things.
So I have two
problems with this. One, I think just trusting somebody to protect what you
need when it’s not in their economic interest is something we’re not going to
see a lot of. People are going to be very cautious, and my guess is it isn’t
going to happen real quick, if at all. And I don’t
think some of it’ll happen at all. I think we’ll see people using it for
various things, but I think it’ll have some limits. It may go further than I
expect, and maybe it will. I’m not that good at forecasting the future, or
haven’t been. But I’m reluctant personally, and I don’t think everybody’s going
to want to move there. There’s way too much that people are unwilling to give
up control over.
And
the other side of it, too. Unless we’re going
to get to a point where communication connections can’t be interrupted, power
lines can’t be interrupted, you’re basically dependent on the whole
infrastructure being completely reliable. And in hurricanes and some kind of
natural disasters, that isn’t going to happen. So I think cloud computing may
have some big possibilities and it may be a big deal, but I’m dubious about how
far it’s going to go. It isn’t going to replace everything. Today people are
still using punched cards. I mean, you go way back.
So I don’t think see
the old stuff going away. I see it as another option, but it will almost
certainly have some benefits, and people will use it. I’m not sure how widely
it’s going to get used, but it may be more than I think right now. But they’ve
got a lot of challenges to figure out how to make it really widely used, and
I’m not sure they’ve got their arms around it yet. They have got to get quality
under much better control than they have, and maybe the TSP will help with
that. Certainly it would be nice if it did.