This interview was provided courtesy of the Computer History Museum.
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?
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
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
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?
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
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.