Time Bandits

Trading quality for time is little more than a fantasy

Steve McConnell, chief software engineer at Construx Software Builders Inc., is a well-known consultant and the author of several highly regarded books, which include Rapid Development: Taming Wild Software Schedules (Microsoft Press, 1996) and After the Gold Rush: Creating a True Profession of Software Engineering (Best Practices) (Microsoft Press, 1999). He also serves as editor-in-chief of IEEE Software magazine. He has worked in the software industry since 1984 and is considered an expert on rapid development methodologies and software construction practices.

Tom Spitzer and Jack Hakim caught up with McConnell as he was preparing for his keynote presentation at the Software Development 2000 Expo in San Jose, Calif. Steve McConnell has strong opinions about the impact of Internet time on the quality of software engineering. In this interview, he discusses the consequences of this trade-off and the need to create a true software engineering profession to alleviate this practice.

Spitzer: In your books and presentations, you emphasize the low productivity and poor quality of many software projects. Contrasting your views with the notion of Internet time, there’s been a perception that organizations have been putting Web services online at a fairly rapid rate. Do you think that’s just a case of us believing in our own hype, or do you think there’s something there in terms of people being better able to get useful things into production quickly?

McConnell: I think there’s a big question about what makes something useful. If you look at what people are putting into production on the Web from a customer-service point of view, there’s a lot of great stuff that provides value on the Web. From a programming-complexity point of view, we’re still looking at, as far as I can see, very basic kinds of applications; we’re looking at taking orders, getting information out of a database, and populating tables. I admit that there are a couple of higher-end sites like Amazon. com, which captures user histories and does a reasonably good job of offering suggestions to return visitors, but by and large, there are not many interesting things happening yet. The data entry forms are quite primitive, and the responsiveness and reliability of services delivered via the Web fall far short of what we expect from Windows. So I think our standards are actually pretty low — even calling these things Web applications is being somewhat generous.

Spitzer: You talk quite a bit about risk management in Rapid Development. How has the risk profile for software projects changed?

McConnell: I don’t see that the risk profile of the average project has changed very much; I think the average project basically does not address risk in any meaningful way. The key success factor continues to be people’s domain expertise, so they are using the brute force of experience to obtain whatever successes they are achieving.

Spitzer: It seems to us that requirements risk is even greater now than it was in the client/server era. What are the elements that go into understanding requirements? Have you seen people using more innovative ways to get at requirements?

McConnell: No, I haven’t seen any more innovative ways. I think that there have been several good books written on the requirements topic within the past 12 to 24 months. This whole topic area is one I addressed in After the Gold Rush. We’ve had very good practices available for many years, and the problem that we’re facing isn’t so much a software engineering research problem, it’s more of a technology-transfer problem: How do you get these good practices into widespread use? I think the big thing that’s missing is any sort of infrastructure for training professional software developers. Developers tend not to get trained in school, and they tend not to receive training, other than very technology-specific, once they get out of school. I really think that is the barrier to adopting effective practices.

Hakim: Are you seeing that the problem is a lack of software engineering curricula and that the people getting computer science degrees don’t have practical experience? Or do you see that the problem results from companies putting people on death marches and not allowing people to look at anything besides immediate, short-term issues?

McConnell: I think it’s all of the above and more. We only have 40 percent of developers graduating with computer science degrees or MIS degrees. So right off the bat, we have 60 percent who don’t graduate with a relevant degree. They’re picking up their sole training on the job or through training that their employers offer. Of that 40 percent, I think a lot of the education they receive is not all that practical. If you look at traditional computer science and engineering, science is about advancing the state of knowledge and engineering is about solving existing problems in a practical way. If you look at the definition, you really don’t need 25,000 new computer scientists graduating each year. But you do need far more people trained in a more standardized engineering approach to applying the knowledge that we do have to solving practical problems.

There’s a real absence of undergraduate software engineering degree programs. A few degree programs have gotten under way in the United States recently; I think we have five programs now — none that have actually graduated classes. There’s been a lot of work going on to define curricula for undergraduate software engineering programs and get additional programs established, but obviously this effort has long lead times. I think 10 years from now we’ll have at least a couple of dozen active software engineering programs, but even at that point we won’t be graduating as many software engineers as we need.

Hakim: The challenge to me seems, at least in part, that, because it’s going to take a long time to solve this in academia, the industry itself has to find a way to start instilling engineering practices. Do you think we’ll reach a point where the economic incentives will encourage that?

McConnell: I think we’ll reach that point eventually, but I’m not sure that’s going to happen during my working lifetime. The labor shortage among programmers has been an issue for the past 30 years, and the perception is that it’s getting worse, not better. I happen to think that perception is wrong, although there may be a local peak with Internet development. If you compare our situation today with statistics on the job market from 30 years ago, you’ll see that right now there’s roughly a 10 percent labor shortage among programmers in North America, and 30 years ago it was roughly a 30 percent labor shortage. It’s started to get better — I can see where in another 30 years economics will kick in, and there will be a widespread incentive to create more systematic employee development programs.

I do think we already see limited instances where the economic [incentive] is working; this tends to happen in fairly mature technology areas, where the factor that distinguishes one product from another is a very high usability or reliability requirement.

The technology transfer model, initially published by Everett Rogers and popularized by Geoffrey Moore in his book Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers, Rev. Ed. (HarperBusiness, 1999), has an awful lot of relevance to software engineering. As long as you’re in an early adopter phase, early adopters are very, very tolerant of usability and reliability shortcomings. It’s quite amazing to me, really, that users are so tolerant and willing to buy beta software that’s not very reliable.

Spitzer: At the same time, with the difficulty that we all have recruiting programmers, you would think we would want to make our organizations more efficient — so we can get more out of the few folks we have.

McConnell: That’s an interesting point. I think that there’s a bit of a mistake in the conventional wisdom. If you look at the difficulty organizations have recruiting programmers, a lot of organizations let their programmers run free throughout their organizations, without much discipline or oversight, thinking that’s the best way to attract and retain them. Many companies are finding that that’s not true. A lot of them have projects in a lot of trouble, and turnover can be pretty high. Organizations that take a more systematic approach to software development and in particular, those that adopt the software capability maturity model (CMM) find that their retention increases dramatically. One in particular, Telecordia Technologies Inc. (formerly Bellcore) was assessed last summer at CMM level 5. When they started the process initiative, they had very high turnover rates. At this point, their turnover is in low single digits. Every single measure of success, including quality, customer satisfaction, [and] project cost, has turned around.

Hakim: I want to go back to something you said earlier. You implied that quality is one of the key benefits, and we exist in a world right now where due to the Web, there’s lots of competition. Will quality become more important as a differentiator — as people can select from a number of competing business-to-business (B2B) Web services?

McConnell: Absolutely. We’ve been in the phase where, in both business-to-consumer (B2C) and B2B commerce, the fact that you could order something online was a big deal, in and of itself. People thought it was great to be able to order online, and they weren’t that concerned with the reliability. They were after the novelty of this new capability, and as we know, early adopters are highly tolerant of problems with new technologies.

As it moves into the business space, its novelty wears off. When you spend 20 minutes entering your order at grocery. com and grocery.com can’t take your order, that gets frustrating. You start to think that maybe you should just go to the grocery store. It’s very natural to start thinking that if this is happening to one customer, it’s happening to all, or at least many, of them. Once we get through the early adopter phase and into the early majority and late majority adopter phases, customers will become more critical, and reliability will become much more important.

Hakim: To what extent do you believe that management unrealistically tries to dictate the deadline and the feature set and expects the programmer to make trade-offs between quality and process?

McConnell: Well, I think there’s a perception that your people are able to trade quality for time. But as a practical matter, on a typical project, 40 to 80 percent of the project cost is spent on unplanned rework, correcting defects introduced earlier in the project; so this idea that you can trade quality for time is not the case. The way to shorten the time it takes to complete something is to do a better job of building quality into the software in the first place. This [quality vs. time trade-off], I think, is nothing but a cherished fantasy that people would like to believe, but in reality it doesn’t work out very well. We have mountains of evidence to the contrary, showing a pretty strong track record for organizations that have taken more of a quality focus. To get control over schedules and cost, you’re going to have to emphasize quality.

Hakim: The reason that we feel this occurs is that, if you force an early working version that eventually evolves into the product, you can get a lot of surface done, [albeit] with very poor architecture and design. So you’re surfacing feature and functionality, without having quality architecture to support the final delivery.

McConnell: I use the term surface area, as well. I think the surface area can be useful as an indicator of progress, but the fact that it does actually work can be a problem. Because people don’t have training in software engineering and management doesn’t really know how to monitor progress very well, they look at false signs of progress on an application. Developing a UI [user interface] prototype is one of the better ways to counter it because it also exposes a great deal of surface area quickly — as long as expectations are managed and people recognize it’s all smoke and mirrors, and not real software.