Excerpts from Software's Chronic Crisis
Scienfic American: Trends In Computing
Despite 50 years of progress, the software industry remains years-perhaps decades-short of the mature engineering discipline needed to meet the demands of an information-age society
Denver's new international air port was to be the pride of the Rockies, a wonder of modern engineering. Twice the size of Manhattan, 10 times the breadth of Heathrow, the airport is big enough to land three jets simultaneously-in bad weather. Even more impressive than its girth is the airport's subterranean baggage-handling system. Tearing like intelligent coal-mine cars along 21 miles of steel track, 4,000 independent "telecars" route and deliver luggage between the counters, gates and claim areas of 20 different airlines. A central nervous system of some 100 computers networked to one another and to 5,000 electric eyes, 400 radio receivers and 56 bar-code scanners orchestrates the safe and timely arrival of every valise and ski bag.
At least that is the plan. For nine months, this Gulliver has been held captive by Lilliputians-errors in the software that controls its automated baggage system. Scheduled for takeoff by last Halloween, the airport's grand opening was postponed until December to allow BAE Automated Systems time to flush the gremlins out of its $193-million system. December yielded to March. March slipped to May. In June the airport's planners, their bond rating demoted to junk and their budget hemorrhaging red ink at the rate of $1.1 million a day in interest and operating costs, conceded that they could not predict when the baggage system would stabilize enough for the airport to open.
To veteran software developers, the Denver debacle is notable only for its visibility. Studies have shown that for every six new large-scale software systems that are put into operation, two others are canceled. The average software development project overshoots its schedule by half; larger projects generally do worse. And some three quarters of all large systems are "operating failures" that either do not function as intended or are not used at all.
A quarter of a century later software engineering remains a term of aspiration. The vast majority of computer code is still handcrafted from raw programming languages by artisans using techniques they neither measure nor are able to repeat consistently. "It's like musket making was before Eli Whitney," says Brad J. Cox, a professor at George Mason University. "Before the industrial revolution, there was a nonspecialized approach to manufacturing goods that involved very little interchangeability and a maximum of craftsmanship. If we are ever going to lick this software crisis, we're going to have to stop this hand-to-mouth, every-programmer-builds-everything-from-the-ground-up, preindustrial approach."
The picture is not entirely bleak. Intuition is slowly yielding to analysis as programmers begin using quantitative measurements of the quality of the software they produce to improve the way they produce it. The mathematical foundations of programming are solidifying as researchers work on ways of expressing program designs in algebraic forms that make it easier to avoid serious mistakes. Academic computer scientists are starting to address their failure to produce a solid corps of software professionals. Perhaps most important, many in the industry are turning their attention toward inventing the technology and market structures needed to support interchangeable, reusable software parts.
"Unfortunately, the industry does not uniformly apply that which is wellknown best practice," laments Larry E. Druffel, director of Carnegie Mellon University's Software Engineering Institute. In fact, a research innovation typically requires 18 years to wend its way into the repertoire of standard programming techniques. By combining their efforts, academia, industry and government may be able to hoist software development to the level of an industrial-age engineering discipline within the decade. If they come up short, society's headlong rush into the information age will be halting and unpredictable at best.
Then again, the industry has heard tell many times before of "silver bullets" supposedly able to slay werewolf projects. Since the 1960s developers have peddled dozens of technological innovations intended to boost productivity-many have even presented demonstration projects to "prove" the verity of their boasts. Advocates of object-oriented analysis and programming, a buzzword du jour, claim their approach represents a paradigm shift that will deliver "a 14-to-1 improvement in productivity," along with higher quality and easier maintenance, all at reduced cost.
There are reasons to be skeptical. "In the 1970s structured programming was also touted as a paradigm shift," Curtis recalls. "So was CASE [computer-assisted software engineering]. So were third-, fourth- and fifth-generation languages. We've heard great promises for technology, many of which weren't delivered."
Meanwhile productivity in software development has lagged behind that of more mature disciplines, most notably computer hardware engineering. "I think of software as a cargo cult," Cox says. "Our main accomplishments were imported from this foreign culture of hardware engineering-faster machines and more memory." Fisher tends to agree: adjusted for inflation, "the value added per worker in the industry has been at $40,000 for two decades," he asserts. "We're not seeing any increases."
"I don't believe that," replies Richard A. DeMillo, a professor at Purdue University and head of the Software Engineering Research Consortium. "There has been improvement, but everyone uses different definitions of productivity." A recent study published by Capers Jones-but based on necessarily dubious historical data-states that U.S. programmers churn out twice as much code today as they did in 1970.
The fact of the matter is that no one really knows how productive software developers are, for three reasons. First, less than 10 percent of American companies consistently measure the productivity of their programmers.
Second, the industry has yet to settle on a useful standard unit of measurement. Most reports, including those published in peer-reviewed computer science journals, express productivity in terms of lines of code per worker per month. But programs are written in a wide variety of languages and vary enormously in the complexity of their operation. Comparing the number of lines written by a Japanese programmer using C with the number produced by an American using Ada is thus like comparing their salaries without converting from yen to dollars.
Third, Fisher says, "you can walk into a typical company and find two guys sharing an office, getting the same salary and having essentially the same credentials and yet find a factor of 100 difference in the number of instructions per day that they produce." Such enormous individual differences tend to swamp the much smaller effects of technology or process improvements.
After 25 years of disappointment with apparent innovations that turned out to be irreproducible or unscalable, many researchers concede that computer science needs an experimental branch to separate the general results from the accidental. "There has always been this assumption that if I give you a method, it is right just because I told you so," complains Victor R. Basili, a professor at the University of Maryland. "People are developing all kinds of things, and it's really quite frightening how bad some of them are," he says.
Photo: David Fisher; AS CEO of Incremental Systems, David A. Fisher learned firsthand why software components do not sell. Now he supervises a $150million federal program to create a market for software parts.
Mary Shaw of Carnegie Mellon points out that mature engineering fields codify proved solutions in handbooks so that even novices can consistently handle routine designs, freeing more talented practitioners for advanced projects. No such handbook yet exists for software, so mistakes are repeated on project after project, year after year.
DeMillo suggests that the government should take a more active role. "The National Science Foundation should be interested in funding research aimed at verifying experimental results that have been claimed by other people," he says. "Currently, if it's not groundbreaking, first-time-everdone research, program officers at the NSF tend to discount the work." DeMillo knows whereof he speaks. From 1989 to 1991 he directed the NSF'S computer and computation research division.
Yet "if software engineering is to be an experimental science, that means it needs laboratory science. Where the heck are the laboratories?" Basili asks. Because attempts to scale promising technologies to industrial proportions so often fail, small laboratories are of limited utility. "We need to have places where we can gather data and try things out," DeMillo says. "The only way to do that is to have a real software development organization as a partner."
There have been only a few such partnerships. Perhaps the most successful is the Software Engineering Laboratory, a consortium of NASA'S Goddard Space Flight Center, Computer Sciences Corp. and the University of Maryland. Basili helped to found the laboratory in 1976. Since then, graduate students and NASA programmers have collaborated on "well over 100 projects," Basili says, most having to do with building ground-support software for satellites.
Brad Cox, like Fisher, once ran a software component company and found it hard going. He believes he has figured out the problem-and its solution. Cox's firm tried to sell low-level program parts analogous to computer chips. "What's different between software ICs [integrated circuits] and silicon ICs is that silicon ICs are made of atoms, so they abide by conservation of mass, and people therefore know how to buy and sell them robustly," he says. "But this interchange process that is at the core of all commerce just does not work for things that can be copied in nanoseconds." When Cox tried selling the parts his programmers had created, he found that the price the market would bear was far too low for him to recover the costs of development.
The reasons were twofold. First, recasting the component by hand for each customer was time-consuming; NIST hopes to clear this barrier with its Advanced Technology Program. The other factor was not so much technical as cultural: buyers want to pay for a component once and make copies for free.
"The music industry has had about a century of experience with this very problem~" Cox observes. "They used to sell tangible goods like piano rolls and sheet music, and then radio and television came along and knocked all that into a cocked hat." Music companies adapted to broadcasting by setting up agencies to collect royalties every time a song is aired and to funnel the money back to the artists and producers.
Cox suggests similarly charging users each time they use a software component. "In fact," he says, "that model could work for software even more easily than for music, thanks to the infrastructure advantages that computers and communications give us. Record players don't have high-speed network links in them to report usage, but our computers do."
_ Or will, at least. Looking ahead to the time when nearly all computers are connected, Cox envisions distributing software of all kinds via networks that link component producers, end users and financial institutions. "It's analogous to a credit-card operation but with tentacles that reach into PCs," he says. Although that may sound ominous to some, Cox argues that "the Internet now is more like a garbage dump than a farmer's market. We need a national infrastructure that can support the distribution of everything from Grandma's cookie recipe to Apple's window managers to Addison-Wesley's electronic books." Recognizing the enormity of the cultural shift he is proposing, Cox expects to press his cause for years to come through the Coalition for Electronic Markets, of which he is president.
The combination of industrial process control, advanced technological tools and interchangeable parts promises to transform not only how programming is done but also who does it. Many of the experts who convened at Hedsor Park agreed with Belady that "in the future, professional people in most fields will use programming as a tool, but they won't call themselves programmers or think of themselves as spending theLr time programming. They will think they are doing architecture, or traffic planning or film making."
That possibility begs the question of who is qualified to build important systems. Today anyone can bill herself as a software engineer. "But when you have 100 million user-programmers, frequently they will be doing things that are life critical-building applications that fill prescriptions, for example," notes Barry W. Boehm, director of the Center for Software Engineering at the University of Southern California. Boehm is one of an increasing number who suggest certifying software engineers, as is done in other engineering fields.
Of course, certification helps only if programmers are properly trained to begin with. Currently only 28 universities offer graduate programs in software engineering; five years ago there were just 10. None offer undergraduate degrees. Even academics such as Shaw, DeMillo and Basili agree that computer science curricula generally provide poor preparation for industrial software development. "Basic things like designing code inspections, producing user documentation and maintaining aging software are not covered in academia," Capers Jones laments.
Engineers, the infantry of every industrial revolution, do not spontaneously generate. They are trained out of the bad habits developed by the craftsmen that preceded them. Until the lessons of computer science inculcate a desire not merely to build better things but also to build things better, the best we can expect is that software development will undergo a slow, and probably painful, industrial evolution.