Frontier Exclusive Visionary Interview for hardware, software, system related business and and academia
Frontier Journal (FJ): My very first question will be software engineering and technology process. So from being very ad hoc to quite comprehensive and formal now, I would like to ask your comments on how the software process evolved during the past several decades.
Professor Watts Humphrey (WH): Okay. Well. My first real exposure to software process issues was over 40 years ago at IBM. And there was about the way the work was being developed. It was very informal and we had to establish a rather high-level process framework with basic checkpoints for the work. This was so we could understand where the work stood and our likelihood of being able to ship products on a reasonable schedule. This is an organization of about 4000 people in 15 laboratories so it was very difficult to know the status of all the work without some basic framework that was basically established when product development work could start. When we could announce a product for customer availability. When we would go through various tests and when we could ship products to customers. And so we established this rather high level. We used it as a basis for managing and planning and over the years people have found that refining that somewhat and improving it helps a great deal in terms of managing costs and schedule and making more realistic commitment. The process has stayed at a fairly high management level until about 19...started working on processes at a more personal level. What we found was that most process work was at such a high level that it did not actually help the development people do their work. And so the SCI developed what was known as the personal software process and the team software process to provide much more...This is largely, let's say, this is a relatively specialized movement. The SCI has done this with the PSP and TSP and the agile community is also implementing or defining measures of a similar sort, basically to guide the developers in how they do their work. With such guidance efficiencies as greatly improved. Okay?
FJ: Okay, about software process. Let's focus on the technical aspect of software process first. So nowadays we have software process incremental type of software process become the mainstream in the industry. So from technical point of view, the software process can be further classified into macro process, addressing, developing environments like IBE, CD or something like. And my co-professor addressing development tools. Do you have any comments on recent progress in both software macro process and software micro process?
WH: Well I think the macro process idea and cyclic processes and spiral models and that sort of thing have gotten a lot of press. People think they're something new but it should be recognized that the idea of building products in small increments is something that has been used for 50 years. I mean, it is not new. It's a way of talking about it, but by and large, the development community has known how to do this forever and we've always done it that way. So there's a good deal of confusion about these macro processes where people think spiral models are new and that sort of thing. They're not. So I think the idea of processes as sort of big things that people implement I think is a misunderstanding. Processes are most useful when they actually relate to the specific work being done and they're customized to the team or the project and to the organization using them. And I think a lot of the discussion about this is much too high level and that sort of thing. Okay?
FJ: Yes. Professor Humphrey, you made a significant contribution to CMM and you developed a PSP and a TSP. So social aspect of software process, talking about social dynamics and human aspects of project management. What is the key difference between a leader and a coach in any software project team? Can a manager be both a coach, a leader as well as a manager?
WH: Well it is possible for managers to develop a coaching style but it's very difficult for managers to really act the part of the coach because the manager's job is to use the team to build a product. So the manager's objective must be to build a product. That's what management hires them for, that's what they're there for. So it's their job to get a product produced. The coach's job is to build the team. So the coach is in a sense quite different from the manager in terms of objectives. The coach is obviously interested in having a successful project result but the coach's objective is essentially used to build the team, as opposed to the team leader who's using the team to build the product. So the coach is really focused on improving capability...coaches are focused on that. And all managers are essentially focused on getting a product delivered.
FJ: I see. I see. So every software project is different. People say "one size does not fit all." So is it possible for us to have a working software process that could be customizable? The software process could be highly customizable, personalized as well as even adaptable. For example, we have model driven software process, model driven requirements. Is it possible for us to have model-driven software process or things like that?
WH: Well the objective of a process, and it's what we do specifically with we show teams how to define their own process. And the process that a team uses for a project really must be customized by the team for that project. And the reason for that is the specifics to build a product, vary a great deal depending on what kind of product it is and the knowledge and skill of the team. I mean the team experimental and prototype work, but if they don't they certainly should. So the same project might have a different process depending on the skills of the team members. Similarly a maintenance project, maintenance and enhancement project, would have to have a whole series of different priorities depending on the kind of fixes being implemented and which modules get enhanced, so there'd be a different framework and a different approach for many different elements of the job. So our contention is, and our experience has demonstrated, that when development teams define their own processes, they're most likely to use them, the process is most likely to fit the job they're doing, and it's much more likely to be in sufficient detail and sufficiently suitable to the team so that it helps them produce, define a detailed plan. Okay?
FJ: I see Okay. So what do you think about software process automation?
WH: I believe process support, tool support for processes is extremely important. One of the key issues we've found is that developers basically resist gathering all the data that they should. After they have considerable process experience they get used to it but at least initially it's hard for developers to really gather data with the accuracy and precision and regularity that's really required to measure and manage a project. It's not really automation because the project is never going to be, so to speak, turned on and run. It has to support people because this is creative work and it must involve people so that the actual development work is done by people with the support of tools. And tools for that reason are extremely important.
FJ: So Professor Humphrey you spent nearly three decades at IBM and you have been at SCI at Carnegie Mellon University for around, I think, two decades. So based on your experience, both industry experience and academic experience, what do you think about software productivity and software capability, the gap between those two have been widened instead of being narrowed. Why does that happen?
WH: What gap are you talking about?
FJ: Software productivity gap.
WH: Well, I think there's a great deal of confusion about that. First of all it's extremely hard to know what productivity really is and I hear a lot of people talking about productivity but generally what they seem to mean, when I really focus on getting people to explain what they're talking about, they're really talking about predictability. I mean, when we think about the job of producing software we're talking about solving problems. And that's fundamentally what the job is. The job of the programmer, by and large, is to take an ill-defined problem and figure out precisely what needs to be done and solve that problem with the aid of a computer or computer network. And that's what the programmers does. Is to understand problems and figure out how to solve them. And talking about productivity in that case it's not like a factory where you're producing nuts and bolts like devices. This is a problem solving issue and it depends on the complexity of the problem and the degree to which the people who have the problem, understand it. So I think the whole debate about productivity, by and large, is a waste of time. I think it's a misunderstanding. It's true you want people to be efficient in producing code, and you could certainly get at that, and there's a serious productivity problem there in terms of the way people spend their time when they develop software. So I'm happy to talk about that: the efficiency of the work. But productivity in the classical sense, I think, is a misleading term.
FJ: So talking about software productivity and manageability, I would like to bring the latest issue about software cost models and software metrics. Could you let us know a little bit about the state of the art on both software cost model and software metrics?
WH: Well, the cost model issue, again, I feel is a misleading one. Fundamentally what people have done is to take data on a large project and put that data together and say, if you have a similar project like that here's what it'll cost based on historical experience. But it's not useful for making a commitment for a project. And my strong disagreement with the model framework is people seem to view that as a way to run a model and use that as the basis for estimate of plan. It should never be used that way. It can be used to guide making estimates and plans but it should never be used to generate the plan. The reason I say that is when you think of building a house, for example, you don't use a model to run off what a house would cost. You actually get the builder to estimate what this house is going to cost. And the builder, when he or she does that, uses data on prior construction projects to give an idea of what the new one will cost. And that's an appropriate way to use models. But when people take a model and fit it with a dozens or more variables to adjust to the complexity of the project and that sort of thing they basically get meaningless results. They're have been studies that show it's really not very good. They're almost worse than misleading. Okay?
FJ: So that brings me to a follow up question. So in terms of software process, as you indicated in one of your previous interviews, PSP and PST are more focusing on technological aspects of software process. It tells the development team how to do it instead of but...CMM and CMMI are basically tells us what to do instead of how to do it. It focuses more on the business aspect and the management aspect of software process. So I would like to ask the following question. Should we combine different views of software process if a single model or process or we have to view them separately? We have different views of software process. We have business view, technological view, and management view - a lot of views. Should we combine them together as one single model or should we deal with them separately?
WH: I believe that we should focus on a single framework for doing a project. And let me back up a little bit. The PST does not define precisely how to do the job. It guides the development team in defining for itself how it will do the job. So the team decides how to do the work. The PST framework helps them actually produce that defined process. Now the reason, basically my sense is from what you're asking, is that you look at a business model as somehow different from the process that the development team is using. And quite frankly if the development team is using a sound process framework for the project and tracks them properly then they can easily produce all the data required by management to manage and track its overall operation. The point is that organizations need high level practices and procedures and frameworks and they need standard checkpoints and milestones for projects and that sort of thing. So this sort of overall business framework is required so that management can understand where one project stands compared to others. This is what I described before what we did at IBM. We had basically a series of phase review checkpoints for every phase of the projects defines its own specific process of how it will do its work within the context defined by management. So those are the two distinct, essentially a management framework with standard checkpoints. You might call that a process if you wish. But the process really I'm talking about is what guides the team in actually planning and managing and tracking its work and reporting it. Okay?
FJ: So it's like a blueprint? So what do you think about the impact of change of software business models on software process? For example, I know we have open source, cloud sourcing, outsourcing and or some kind of new business models, keep on coming. So what do you think about those impacts on software process?
WH: That's a very interesting question. I think that the open source movement, for instance, is quite interesting. If you've read The Cathedral and the Bazaar book, for instance, the idea behind that is essentially personal pride. The developers doing the work is out and visible, it's reviewed by their peers, there's a high degree of professional pride in what they're doing and that is really very impressive and I think is the kind of attitude you want for all professionals if their work really is something they want to be proud of and they want to show it, demonstrate it to others. So I think from an attitude and a professional approach, some of these newer methods are very powerful and I think certainly can be helpful and the kind of professionalism we need. Now with a high level of professionalism then I think we can talk about much more refined process practices that the individuals could follow. So I think some of these new business models actually provide I think really fabulous opportunities for improving the way we do our work. It's kind of hard to know where they're going to go at this point. But I'm quite excited about the opportunity.
FJ: Okay so based on your observation, overall do you think innovation in software and software research is diminishing or sliding? Why?
WH: Well I think there are several pieces here. I think unfortunately a lot of the research work in software for many, many years academic work that has essentially been focused on the same sort of thing for ten, twenty, thirty years without really addressing which I think are critical to the software profession. I think there's a split there between what's really needed by industry and what the community is interested in working on. On the other hand I think the innovation we're seeing, we're not seeing a whole lot of it in the academic community So the real innovation is coming out of the practitioners I think there's some challenges out there that need to be addressed and it comes back in your document but didn't really exist here and that's the quality subject. And I think there's a good deal of and the problem One, quality is nowhere near good enough. Of software. For the kinds of things we have to do in the future. But on the other hand software quality is extraordinarily high. Let me explain that. In order to get a program compared to documents, compared to books and kinds of things that are written as software is, the quality of software has to be much higher than any other material in order to work at all. People talk about defects lines of code when they talk about delivered programs and they talk about maybe five defects in a thousand lines of code as sort of typical quality level. And that's about right; that's about what gets shipped. And typically the kind of defect levels that go into system testing from development are about now, put that in perspective. In a thousand lines of code, at least when you print at least code, takes about 20 pages. So 20 defects in a thousand lines of code means one defect per page. Now that's quite a few for a program but it's not a whole lot when you look at magazines and newspapers. So it's fairly high. When developers get pretty good and they begin to learn good quality methods and that sort of thing they can do much better and we are typically seeing teams that are being tested that have less than per or one defect in 20 pages. But nonetheless, if we talk about in 20 pages of code as typical when you think about a million lines of code, and those are typical small systems today of a million lines of code, they're we're talking about 5000 defects. And while that may be okay for accounting that don't cause disastrous problems, but even accounting systems can, but nonetheless when you've got physical safety that's way too many defects. For systems that people's lives will depend on, we want to get down to where we're talking about defects...a few defects per million lines of code at the most and even that we're uncomfortable with the idea five to ten defects in a program because they still could be dangerous and that's certainly true. So the issue here if you want to get down to five defects...one to five defects per million lines of code, we're talking not two or three defects per 20 pages, we're talking two or three defects in 20,000 pages by looking for defects. The point is the quality thrust in software has to be focused on defining and using statistical measurement methods to really run very disciplined, highly managed, statistically controlled process. And these have to be individual process because individual processes because individuals are the only ones who can manage it. There's a whole movement and that's why we really need to focus on putting the engineers in charge of their own work, building their pride and the quality of what they do, building their ownership and their commitment to their own work. And that's why the PSP is basically designed as a knowledge working And I want to distinguish between the traditional management system, where the management tells the and the workers what to do and when to do it. The knowledge working, which is what the Represents is where the workers actually negotiate with the management on and when. So they end up owning the process. It's their process and they commit to do the job. And this is what we do with the PSP. They commit to do to complete the job. And this is what we do and it's just not a matter getting management to understand why the culture for knowledge work needs to be different. And so that comes back to the point you were making earlier. The whole social aspect of how we do this work is critically important. Okay.
FJ: That makes sense because in large economies every individual and every team becomes highly independent.
WH: That's where the creative work is done.
FJ: Exactly. So Professor Humphrey, I have one more question to go. You have been in the software business for nearly five decades, since the inception of the software business what is your perspective of the future of the software business? Software industry as a whole?
WH: Well, that's a marvelous question and something I've thought about quite a bit. I believe there are two things. First of all, I think in a sense, software will stop being a specialty. Not because it's unimportant but because everybody's going to have to do it. It's like mathematics. You don't see mathematicians out doing a lot of things. Everybody uses mathematics. So in a sense I believe, there will still be professionals who build very unique tools and systems and things of that sort but I believe down the road going to have to be competent in software. Fundamentally this is how we solve problems. And, software...as I've said, the world is getting soft. You don't build your hardware anymore. Just about every system has software in it and so just about any professional needs to be competent and that means we need to take the skills and we need to get them regularized so everyone can use them properly. But a highly disciplined, well managed predictable process for software development will be needed just about in every engineering and science. So I think that's where I see us going because I think the power of software to solve human problems and to improve the quality of life for just about all of mankind, I think, is extraordinary. And so I believe we have tremendous opportunities ahead of us but it does mean that we need to begin to start high quality and pro Okay?
FJ: Professor Humphrey, I appreciate your time and thank you so much.
Back to Home Page