The Future of Software Engineering: Part I

In this and the next few columns, I discussthe future of software engineering. This column focuses on trends inapplication programming, particularly as they concern quality. In subsequentcolumns, I address programming skills, trends in systems programming, and theimplications of these trends for software engineering in general. While thepositions I take and the opinions I express are likely to be controversial, my intent is to stir up some debate and hopefully to shed light on what I believeare important issues. Also, as is true in all of these columns, the opinions Iexpress are entirely my own.

Current Trends

Some 50 years ago when I finished graduateschool, I started to work with computers. For almost all of the intervening time,people have been dreaming up new and better ways to use computing devices and systems.While the volume of application development has grown steadily, so has the listof applications that people want to develop. It seems that the more programs wewrite, the more we understand what we need, and the more programs we add to theapplication-development backlog. So far, the rate of growth in applicationdemand has continued to accelerate.

As economists say, unsustainable trends areunsustainable. However, to date, there is no sign that this growth in demand isslowing. I suspect that it will continue for the foreseeable future, though wewill certainly see changes in the types of application programs. The reason forthis growth is that application programming is a very effective way to meetmany kinds of human needs. As long as people continue devising new and clevererways to work and to play, we can expect the growth in computer applications tocontinue. The more we learn about computing systems and the more problems we solve,the better we understand how to address more complex and interesting problems.Therefore, because human ingenuity appears to be unlimited, the number ofprograms needed in the world is also essentially unlimited. This means that theprincipal limitation on the expanding use of computing systems is our ability tofind enough skilled peopleto meet the demands.

In discussing these topics, I break thesoftware world into two broad categories: applications and systems. I won’t tryto clearly define the dividing line between these categories because that line isboth indistinct and changing. By “application programming,” I refer to solvinghuman problems with computing systems. Here the focus is on defining theproblem and figuring out how to solve it with an automated system. Systemsprogramming focuses on how to provide automated systems, aids, tools, andfacilities to help people produce and run application programs. In looking towardthe future in these areas, I believe that the two most significant issuesconcern software qualityand the demand for skilledpeople. I address application software quality first.

Application Program Quality

The quality of application software today isspotty at best. A few programs are of high quality and many are downright bad.The discussion of application quality has two principal parts. First, computersare being used for progressively more critical business applications. Thismeans that, even at current quality levels, the impact of software defects willgrow. This implies that the demand for high-quality application software willalso grow.

To date, people buy and use software withoutapparent concern for their quality. While they complain about quality problems,software quality has not yet become a significant acquisition consideration. Untilit is, we cannot expect suppliers to measure and manage the quality of their products.However, as has been amply demonstrated in other fields, when quality is notmeasured and managed, it is generally poor.

When the public gets concerned aboutquality, these attitudes will quickly change. It will not take many high-profiledisasters to cause executives to worry. Then, they are likely to demand qualityguarantees and warranties from their suppliers before they entrust theirbusinesses to new computing systems. When customers cannot be assured of the qualityof a software package, they will either go to a competitor or forgo theapplication entirely and continue using prior methods. This would not bebecause automated methods would not have been helpful, but simply because the riskof failure would be too high.

Growing Program Complexity

The second part of the program qualitydiscussion concerns size and complexity. The size and complexity of applicationprograms is increasing. The size data in Figure 1 show just how fast this growthhas been. The IBM size measures are from my personal recollection, theMicrosoft NT size data are from published reports, and the spacecraft size dataare from Barry Boehm [Boehm 1981, Zachary 1994]. The TV data are for theembedded code in television sets and are from a talk by Hans Aerts and othersat the European SEPG conference in June 2000. According to my prior definitions,the IBM and Microsoft products are system software while the spacecraft and TVprograms are application software.

These data show that the size of thesoftware required for various kinds of systems and applications has beengrowing exponentially for the past 40 years. The trend line in the center ofthe chart shows a compound growth rate of ten times every five years. This isthe same as Moore’s law for the growth in the number of semiconductors on achip, or a doubling every 18 months.

While the size growth of system software hasbeen phenomenal, it appears to be slowing, at least from the appearance of theIBM and NT data in Figure 1. I discuss these systems software trends in a latercolumn. The critical point from an  pplicationquality point of view is that the growth trend for applications softwareappears to be continuing.

The Defect Content of Programs

Assuming that the same methods are used, thenumber of defects in a program increases linearly with its size. However, therate at which application program users experience problems is largely determinedby the number of defects in a program rather than their density. Therefore,even though the defect density may stay about the same oreven improve, merely producing larger programs with the same methods willproduce progressively less reliable systems. So, either the quality

of future application software must improve—at least instep with the increasing sensitivity of the applications—or businesses mustlimit their use of computing systems to less critical applications.

Figure 11-1: Program Size Growth

To see why program reliability depends ondefect numbers instead of defect density, consider an example. A 200 KLOC(thousand lines of code) program with 5 undetected defects per KLOC would have1,000 defects. If you replaced this program with an enhanced program with 2,000KLOC and the same defect density, it would have 10,000 defects. Assuming thatthe users followed a similar usage cycle with the new application, they wouldexercise the larger program at about the same rate as the previous one. Whilethis would presumably require a faster computer, the users would be exposed toten times as many defects in the same amount of time. This, of course, assumesthat the users actually used many of the new program’s enhanced functions. If theydid not, they presumably would not have needed the new program.

An Application Quality Example

Oil exploration companies use highlysophisticated programs to analyze seismic data. These programs all use the samemathematical methods and should give identical results when run with identicaldata. While the programs are proprietary to each exploration company, the proprietaryparts of these programs concern how they process enormous volumes of data. Thisis important because the volume of seismic data to be analyzed is often in theterabyte range.

A few years ago, Les Hatton persuadedseveral oil-exploration companies to give him copies of nine such programs[Hatton 1994]. He also obtained a seismic exploration dataset and ran each of thesenine programs with the identical data. The results are shown in Figure 2. Here,the range of calculated values is shown for several consecutive programiterations. As you can see, this range generally increased with the number ofcycles, and after a few runs, it reached 100%. When one of these companies wastold about some of the conditions under which its program gave unusual results, the programmers found and corrected themistakes, and the program’s next results agreed with the other programs.

Figure 11-2: Growth in Seismic ProgramUncertainty

The results produced by theseoil-exploration programs contained errors of up to 100%, and these results wereused to make multi-million-dollar decisions on where to drill oil wells. Basedon this study, it appears that these programs provided little better guidancethan throwing dice. I am not picking on these programs as particularly poor examples.Their quality appears to be typical of many application programs.

The Quality Problem

In discussing the quality of applicationprograms, we need to consider the fact that defective programs run. That is,when engineers produce a program and then run extensive tests, they generally canget it to work. Unfortunately, unless the tests were comprehensive, the testedprogram will likely contain a great many defects.

Any testing process can only identify andfix the defects encountered in running those specific tests. This is becausemany program defects are sensitive to the program’s state, the data values used,the system configuration, and the operating conditions. Because the number ofpossible combinations of these conditions is very large, even for relativelysimple programs, extensive testing cannot find all of the defects.

Since the size of application programs willcontinue to increase, we need to consider another question: will we be able totest these programs? That is, how well does the testing process scale up withprogram size? Unfortunately, the answer is not encouraging. As programs getlarger, the number of possible program conditions increases exponentially. Thishas two related consequences.

1. The number of tests required to achieveany given level of test coverage increases exponentially with program size.

2. The time it takes to find and fix eachprogram defect increases somewhere between linearly and exponentially withprogram size.

The inescapable conclusion is that thetesting process will not scale up with program size. Since the quality of today’sprograms is marginal and the demand for quality is increasing, current softwarequality practices will not be adequate in the future.

The Impact of Poor Quality

As the cost of application mistakes growsand as these mistakes increasingly impact business performance, applicationprogram quality will become progressively more important. While this will comeas a shock to many in the software community, it will be a positivedevelopment. The reason is that suppliers will not generally pay attention toquality until their customers start to demand it. When software quality becomesan important economic consideration for businesses, we can expect softwareorganizations to give it much higher priority.

While one could hope that the softwareindustry would recognize the benefits of quality work before they are forcedto, the signs are not encouraging. However, improved product quality would bein the industry’s best interests. It would mean increased opportunities forcomputing systems and increased demand for the suppliers’ products. This wouldalso mean continued growth in the demand for skilled software professionals.

In the next column, I discuss the need forapplication programming skills and how this need is directly related to thequality problem. Following that, I discuss related trends in systems programming and the implications of these trends for software engineering.

发表时间：2001年一季度

作者：Watts Humphrey

编者按：Watts New - 未来的应用软件质量

编译：冯信