Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

The Rising Costs of Software Complexity


Apr01: The Rising Costs of Software Complexity

It's been a problem for 40 years. Now it's a crisis

Shannon is DDJ's associate news editor. She can be reached at [email protected].


What's the most important problem in computer science? Languages, tools, programmers? Well, according to a growing number of researchers and computer users, it's software complexity. "We've known about this problem for 40 years," says Alfred Spector, vice-president at IBM Research. "This is probably the number one problem...It can't go on."

Spector's research shows that IT spending in the United States is nearly doubling every year. Application development is already a costly process: IBM spent a trillion dollars on the CICS application server platform alone (http://www-4.ibm.com/software/ts/cics/). And software requirements are only increasing — availability, security, integration, scalability, and integrity are becoming more complicated issues even as they become more critical. Many problems today require the application of a collection of technologies, not just one. At the same time, the cost to maintain existing software is rising. "We have to keep fixing the potholes," Spector says. "Code somehow or other rots."

Any number of statistics can be marshaled to illustrate the dire situation: According to a Standish Group research study (http://www.standishgroup.com/visitor/chaos.htm), only about 16 percent of software projects are completed on time and on budget. PC World magazine reports that 22 percent of computers break down every year: In comparison, only 9 percent of video recorders, 8 percent of refrigerators, and 7 percent of big-screen TVs malfunction (see http://www.pcworld.com/features/article.asp?aid=16808). The Software Productivity Research consulting firm (http://www.spr.com/Resources/resources.htm) finds that an average programmer only works about 47 days a year on new development; the other 150 days are spent testing, debugging, or working on projects that get canceled. One oft-quoted statistic holds that users only work with about 10 percent of the features available in most software.

Bridge Building Versus Computer Programming

"The high cost is not due, as you might think, to programmer stupidity," Spector says. "We in research like to think that everybody doing this stuff is just stupid, and that's why it costs so much." Convinced that the true answer is more complicated, Spector coauthored a 1986 paper comparing software development to bridge building. Bridges, it turns out, are generally completed on time and within budget — and once built, they rarely malfunction.

"It's not enough to say that they have an easy problem and we have a hard problem," Spector cautions. The obvious difference is that bridges have physical limitations, whereas software has only theoretical limits. The design of a bridge simply can't be changed halfway through the project without physically tearing down the work that has already been done. But since the work of a program is invisible, it is deceptively easy to introduce sweeping changes midproject. Almost always, these changes will complicate the product.

In another paper authored in 1986, "No Silver Bullet: Essence and Accidents of Software Engineering" (http://www.virtualschool.edu/mon/SoftwareEngineering/BrooksNoSilverBullet.html), Turing Award winner Frederick P. Brooks argued that complexity is part of the essence of software. "Software entities are more complex for their size than perhaps any other human construct because no two parts are alike (at least above the statement level)," Brooks wrote. "If they are, we make the two similar parts into a subroutine — open or closed. In this respect, software systems differ profoundly from computers, buildings, or automobiles, where repeated elements abound. Digital computers are themselves more complex than most things people build: They have very large numbers of states. This makes conceiving, describing, and testing them hard. Software systems have orders-of-magnitude more states than computers do. Likewise, a scaling-up of a software entity is not merely a repetition of the same elements in larger sizes; it is necessarily an increase in the number of different elements. In most cases, the elements interact with each other in some nonlinear fashion, and the complexity of the whole increases much more than linearly."

Spector found that it's the blueprint of a bridge — the extremely detailed, unchanging design — that keeps the project on course. But according to Brooks, it's impossible to create a similar blueprint for a software program. "In the pitiful, multipage, connection-boxed form to which the flowchart has today been elaborated, it has proved to be useless as a design...Nothing even convincing, much less exciting, has yet emerged from such efforts. I am persuaded that nothing will," he said flatly. It's true that languages such as Visual Basic and UML have made significant strides since Brooks wrote those words, but Visual Basic cannot replace hand coding in complicated projects, and UML has yet to achieve broad acceptance among designers.

Interestingly, in the history of bridge building, Spector did find overshot estimates, bloated time frames, and even product collapses. But when a bridge fell down, an investigation commenced and the cause of failure was determined. In the software industry, no such audit takes place: More often, software failures are rationalized and ignored. Software producers do not seem to bear the same burden of accountability as manufacturers of physical goods.

"I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation," wrote Brooks. "We still make syntax errors, to be sure; but they are fuzz compared with the conceptual errors in most systems."

Software's inherent complexity can only be managed through careful design. But the world of commercial development tends to work against good design practices. The swiftly changing market pressures developers to rush out a product — any product. Many large commercial products are created by an army of programmers, each working on a separate piece of the problem. The resulting jigsaw is stitched together any way that works — but without careful, coherent oversight, there's plenty of room for unanticipated interactions in the code.

The Failure of ERP

Consider the example of enterprise resource planning (ERP) software, promoted by companies such as SAP and Siebel. ERP software aimed to replace all the separate departmental systems inside a corporation with one central software system. ERP was supposed to make it possible for a sales order to automatically generate the corresponding adjustments in production, inventory, and accounting. It was integrated, it was end-to-end...and it was insanely complex. "In an ERP implementation project, the ratio of money spent on consulting services to money spent on software is between 5-to-1 and 10-to-1," reported Josh McHugh in an article for eCompany Now (http://www.ecompany.com/articles/mag/0,1640,6580,00.html). Many companies could never get the software to work at all. Just before Halloween 1999, Hershey Food Corp. announced that because of problems with its ERP software, the company was unable to fill orders and get its candy onto shelves. The company reported a 19 percent drop in earnings that quarter. Subsequently, other companies — including Whirlpool and Allied Waste — revealed that they were also facing delays in shipping caused by their new ERP systems. One drug distribution company went bankrupt and filed a lawsuit blaming SAP. The makers of Gore-Tex filed a lawsuit against another ERP vendor (see "News & Views," DDJ, February 2000).

ERP software has often been a failure because it is too complicated to install and use. "We often solve the hardest problems and don't worry whether anyone can use our solutions," Spector admits. "For the most part, today computers are way too hard for most people to use effectively. It's a real problem."

"Andrew Grove, the founder and chairman of Intel Corporation, once joked that at current levels of growth in the tech-support field, early in the new century every person on the planet should be a tech-support specialist," reported Gary Chapman in "No 'Silver Bullet' For Software's Growing Complexity" (Los Angeles Times, November 27, 2000). "Intel employs more than 5000 tech supporters. Much of this is due to software complexity, program bugs, and poor quality in software programming. These all add up to an immense burden on the economy."

This is not a problem that will have a single answer. The complexity of ERP software stemmed largely from its attempt to integrate so many different functions. But the heterogeneity of the technical landscape is only increasing, and interoperability is critical. James Gosling, creator of Java, has harsh words for systems that perform only their own functions with no regard for integration: "That's just confusing. It makes the whole universe hard to use." At the same time, what Gosling calls "the Highlander solution [that is, technologies that attempt to enforce a single homogenous system] tends to be a brutal thing that nobody really wants."

Improving the Software Tools

Gosling points out that software must also struggle to keep pace with improvements in hardware: "Fifteen years of Moore's law is really amazing. People don't understand exponentials very well." But developers are essentially working in the same ways, with the same tools, to create applications that must be vastly more powerful. Emacs, Gosling points out, hasn't changed much in the last decade. And most of the new tools on the market "are trying to save people from the fate of having to write code." Really cutting-edge stuff is still done in Notepad. Gosling says he's working now on an intelligent text editor, something capable of offering "auto-completion on steroids."

This sort of work, according to Spector, is the only promising answer to the problem of complexity. Software production won't be comparable to bridge production until the design process is similarly firm, and if there is hope for software design it will lie not in the commercial sector but in computer-science research. Product-oriented programmers, subject to extreme time constraints and the pressures of an ever-changing market, will invent clever solutions to their dilemmas; but clever workarounds are part of the problem.

Can Research Survive in the Garage?

"The garage" is how Spector refers to product-oriented development environments. "The garage, focused development, has done sufficiently well that it's somewhat unnerving," Spector says. "How do we justify the use of our time doing research... Sometimes we have doubts as to whether we are doing the right thing." But Spector believes that commercial work has achieved short-term success at the expense of long-term progress. In the garage, "there has been proved in many cases to be limited time for fundamental innovation...I think the limitations are becoming hindrances."

For instance, although the theoretical value of code reuse is widely recognized, programmers on a tight deadline are actually less likely to incorporate preexisting components into their work. The component will probably need to be modified anyway, and the time it takes to locate, understand, and adjust the code can't be justified in the short term. And of course such programmers are even less likely to create a reusable component because that would triple the workload.

Researchers, by contrast, have the luxury of time. "If we solve only garage-like problems...we're squandering our resources," says Spector. "As scientists, we should have renewed energy."

Unless or until researchers come up with vastly improved developer tools or a fundamental breakthrough in software design, developers can only attempt to stem the rising tide of complexity. Gosling advises programmers to resist feature creep: It's natural, he says, to see "neat ideas" that could be incorporated into a project. But no changes should be undertaken lightly. "It's not until the third or fourth person comes along, preferably armed with a baseball bat," that Gosling will act on such suggestions. He also advocates "shameless theft" in design: "If you look at all the things in Java, they're all from somewhere."

And usability testing can go a long way toward making software less complicated to consumers. "You bring in average customers and have them use the software. When they have trouble doing so, the appropriate reaction is not 'this user must be stupid,'" usability expert Jakob Nielsen counsels on his web site (http://www .useit.com/). "The conclusion is: 'The developers made some mistakes.'...Doing things right will only add a few percent to the cost of a development project. You will save many times this cost by not having to make expensive adjustments and dot releases."

Although the problem of software complexity has no single answer, Spector manages to make the best of it: "If we don't solve this, we will be continually employed, without question," he smiles.

DDJ


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.