In fact, The Sustainable Computing Consortium is a think tank at Carnegie Mellon University in Pittsburgh that's trying to come up with ways to improve the quality and reliability of software.
Since itsin May, the consortium has lined up support from a blue-chip roster of companies and government agencies that includes the likes of NASA, Alcoa, General Motors, Merck, Oracle, Cisco Systems and Microsoft.
William Guttman, a professor of economics and technology at Carnegie Mellon University who directs the consortium's work, knows he's tackling what might be considered a "Mission Impossible." But with poorly designed software costing businesses tens of billions of dollars in lost productivity and compromised data, he figures it's well worth the effort.
CNET News.com recently caught up with the 40-year-old Guttman to talk about the Sustainable Computing Consortium and how it might achieve its goal of stopping--or at least reversing--what he views as a disturbing trend toward designing bad software.
Q: What was the motivation behind the sustainable computing initiative?
A: Recent geopolitical events have accelerated an already intense national debate on the broad issues surrounding the integrity, dependability and survivability of much of our critical infrastructure. In no other area is this more pertinent than in information technology.
Is software in such bad shape?
Nobody knows how bad the state of software really is. It's as if, in constructing a building, all the drywall went up before anyone looked at what was inside. The only confidence we have in the safety and soundness of the buildings we are sitting in is that there are all sorts of efforts we make as society, such as fire-retardant materials, engineering standards, etc.
The problem with software is that it is unique among complex engineered products, insofar as we have very little ability to understand the inherent level of quality in the product.
What can be done about that?
The effort of the consortium is really about understanding the costs of poor quality and poor security through measurement and quantitative research. There isn't any truly reliable research or major data-collection effort to understand that right now. The data are relatively crude and anecdotal.
Why should people worry about this issue? What's at stake?
Software has become so pervasive. We as a society rely on it for so many things. When there is a problem, when there are bugs, the cost is often much more than we ever imagined.
For example, Toshiba had a big class-action suit against it because of buggy software in its laptops. It settled the suit for $2.1 billion. Ten years ago, it might have settled that suit for millions instead of billions. But now, a single instance of software malfunction causes problems in the billions of dollars to fix because software is taking on more and more responsibility for the functioning of our industrial society. It's not hard to imagine that instead of a $2 billion incident, you could have a $10 billion or $20 billion incident in the future. So the stakes are getting much higher.
|No matter the type of application it is, you can count on finding 30 bugs per 1,000 line of code on average.|
What has caused software quality to become such a big problem? What are the economics that have created this situation?
One reason we wanted to bring users and producers of software together into a single forum is that there is a cost related to improved security and reliability. There is a sort of trade-off triangle in terms of investment. On one side, you have software features; on another, you have time-to-market; and on the third, software sustainability, which encompasses reliability, dependability and security. To the degree that your priorities are features and time-to-market, you sacrifice the sustainability leg of the triangle. Why did problems develop, you ask? Trade-offs were made to get products out with as many features and as quickly as possible.
Along that line of thinking, have software quality problems been compounded by the Internet boom? When being first to market overshadowed everything else?
Certainly, the Internet start-up business model was taken to its ultimate extreme. In that model, speed-to-market was everything. But the impact of the Internet is more interesting in the fact that it provides effectively infinite connectedness, so that everyone is part of a single network. The exposure in terms of security to worms and viruses is orders of magnitude beyond where it was before the Internet.
Is awareness of the problem growing?
I think it is. The creation of this consortium is a reflection of that awareness. Microsoft's recent drive, mandated by (Chairman) Bill Gates, to improve software quality is also an indication. Quality, security and reliability are becoming features in themselves and something companies and individuals are demanding more of.
Are certain types of products or software vendors worse than others in terms of their record on quality?
I have a colleague who says bugs are agnostic. No matter the type of application it is, you can count on finding 30 bugs per 1,000 lines of code on average.
|Sometimes I say I'm repaying my debts to society because I'm the source of so many bugs.|
How much of the blame for malfunctioning software lies with consumers, for misusing or mismanaging software?
Products are a reflection of the marketplace. When consumers say what they really want is reliability, that will start to feed back into the product because producers will say, "I can market this." I think that it's ultimately about desire. We use cell phones despite the fact that they drop signals or have static. Software has been such a powerful and positive development from the standpoint of personal productivity, we put up with the occasional document being lost or computer crashing.
So how do you start to improve the reliability of software? Is liability part of the answer?
It's difficult because software is kind of a tricky beast. Is it a product or a service? To the extent it's a service, it's not subject to product liability laws. And what are the implications of the Uniform Computer Information Transactions Act? (The act) is focused on limiting liability because its origins are in the free software movement.
What about software insurance as a way to push improvements?
I think insurance can play a tremendously positive role in the future development of the industry. If you look at other complex engineered products, such as cars or buildings, there are insurance markets around those industries. Insurance can encourage the development of risk-mitigation technologies and behaviors, and risk mitigation is the name of the game. For instance, car insurance creates positive incentives by offering discounts for airbags and antitheft systems. In fact, one of the members of the consortium is an insurance company, American International Group, and they sell a product called "E-business risk."
What does the consortium hope to achieve? What will be your first order of business?
The very first thing is to identify, in cooperation with our members, our criteria. What are users looking for in quality, dependability and security? What are producers' devilishly hard problems? What would help them manage their engineers better if they could measure X?
In the long term, the establishment of the consortium will lead to the emergence and evaluation of innovative, enabling technologies and development methodologies. At the same time, it will influence the formulation and implementation of future public policy.
Why did you personally get involved in the consortium?
I was actually the chairman and CEO of a software company called Printcafe. Sometimes I say I'm repaying my debts to society because I'm the source of so many bugs. I've also worked as an economist at the World Bank, and at the Organization for Economic Cooperation and Development in Paris. So, this is something that intrigued me because it is a multidisciplinary problem of which economics is a central part. The scale of the problem and the importance to our economy and national security were also factors for getting involved.