Computerdom’s Winds of Change Will Bring a Blast of Fresh Errors
In his most private moments, Intel Chief Executive Andy Grove must rail against the seeming injustice of it all. Unlike tainted Tylenol, Intel’s Pentium hasn’t hurt anyone. The Pentium is hardly the Corvair or the Pinto of microprocessors that causes life-ruining computational crashes; it is not “Unsafe at Any Speed.”
Yet Intel has effectively been cast as the outrageously arrogant GM (General Microprocessors?) of today. The digital masses on the Internet rising up in righteous wrath to smite this silicon giant are now computerdom’s Ralph Naders. Even IBM--once the Goliath of its time--has unabashedly sided with the forces of consumerism. Clearly, Intel’s miscalculations have been on a scale far grander than those of its Pentium. The result is that the world’s most profitable microprocessor company has deservedly taken a hit.
But the real issue here isn’t the shameful spectacle of a successful innovator with a flawed product arrogantly insisting that it knows what’s best for customers and getting into a statistical shootout with IBM over just how bad the flaw is. No, the important issue involves the painful reality that these products are now hurtling beyond the level of complexity that can successfully be designed and tested.
Pentium-type problems will prove to be the rule--rather than the isolated, aberrant exceptions--as new generations of complex hardware and software hit the market. More insidious errors and harmful bugs are inevitable. That is the new reality. The Pentium is merely today’s sour taste of tomorrow’s complexity. This is the dirty little secret that everyone from Silicon Valley to Redmond, Wash., to Route 128 in Massachusetts knows but would rather not discuss in public.
The problem is particularly acute for microprocessors, which are essentially sophisticated software crystallized into silicon. Roughly every three years, a new generation of microprocessor emerges. Those chips invariably run about five times faster, are filled with four times as many transistors and offer far greater functionality than their immediate predecessors. This has been the immutable rule of microprocessors for the past 20 years. Indeed, in another three years there will be a next-generation microprocessor that makes today’s Pentiums seem as fast as sedated sloths.
All these exponential improvements in microprocessor price and performance come at the cost of complexity. Testing all this complexity to assure that there are no mistakes in design or manufacture becomes a task that is in itself orders of magnitude more complex with each new generation. It now seems fair to say that our ability to successfully test microprocessors has been outstripped by the product’s inherent complexity.
The same is increasingly true for software--why do you think Microsoft and other leading software companies are always late shipping their products? The problem will get worse over time, not better.
What further complicates this complexity is the difficult question of what should be tested. Currently, IBM and Intel are in hot dispute over dueling spreadsheet calculations: Intel assumes a thousand calculations per hour; IBM postulates 5,000 calculations per second. Whose assumptions are more realistic? If all you’re doing is word processing and desktop publishing, errors in floating point logic are irrelevant to you. Then again, what happens if there is an error in a microprocessor that leads to your word processor randomly deleting the word not every few thousand times it appears? Is that a nuisance? Or is it a software recipe for a communications disaster? The issue of how to test--and along what dimensions--will clearly become one of the most important design issues of tomorrow.
You can be sure there will be lawyers arguing that microprocessor companies and their software brethren haven’t performed adequate testing before loosing their products on an unsuspecting marketplace. Woe betide the executive who has the “smoking e-mail” in his hard drive detailing that he knew of the bug but considered it too insignificant to fix. Testing seems destined to become tomorrow’s legal battlegrounds as consumers demand more value and less risk from their digital consumption. If they don’t get it, watch them sue.
But as more and more types of software interact with the microprocessor--indeed, as more and more types of memory chips and video and sound chips network with the microprocessor--it becomes mathematically impossible to test for all the permutations and combinations that might lead to subtle flaws or humongous errors. Customers--not vendors--will be catching more and more of tomorrow’s bugs.
This has two immediate implications. The first is that hardware will become more software-like. Microprocessors will increasingly be designed for remote diagnostics and a software fix to quickly bypass or repair logic flaws. In other words, silicon will be designed to be remotely re-edited, not just replaced. (Unless, of course, it’s simply cheaper to throw away the old microprocessor.)
The second is that smart individuals and organizations will not trust a single microprocessor or software package for their most vital calculations. For example, people will make sure that spreadsheets are calculated on Microsoft Excel as well as on Lotus 1-2-3, and on PowerPCs as well as Pentium processors. The Boeings, GMs and Mercks of the world would be wise not to become too dependent on a single computational platform.
As our computers use complexity to become more powerful, that same complexity also makes them more vulnerable. We have to take steps to make sure we are not harmed by their vulnerability.
Michael Schrage is a writer, consultant and research associate at the Massachusetts Institute of Technology. He writes this column independently for The Times. He can be reached at schrage@latimes.com by electronic mail via the Internet.
More Innovation
* For a collection of recent Innovation columns by Michael Schrage, sign on to the TimesLink on-line service and “jump” to keyword “Innovation.”
Details on Times electronic services, B4
