| by David Rice
Software is becoming the foundation of modern civilization. Software affects, in one way or another, vast aspects of our everyday lives, whether in apparent aspects such as checking e-mail, surfing the web, or online banking, or less obvious aspects like providing water, power, or national defense. Every day, we have less choice about how and when software touches us.
The quality of software matters greatly. Indeed, the more we rely on software, the more important the quality of its composition. Unfortunately, current market incentives do not promote high-quality, secure software. Software remains inexcusably dysfunctional, unreliable, expensive, and much harder to use and far less effective than it ought to be. Insecure software is also dangerous. Cyber criminals, as well as aggressive nation-states, are actively exploiting vulnerabilities in software to their advantage and to everyone’s loss.
Software quality is not just a technology issue; it is also an economic one. Incentives matter. Without meaningful market incentives, buyers will not demand, and software manufacturers will not produce, software suitable for the tasks and position we have given it within modern civilization. To make software better will require not only technical solutions, but also new market incentives that encourage, rather than punish, software manufacturers desiring to produce high-quality, secure software.
The following excerpt is from my book, Geekonomics: The Real Cost of Insecure Software (Addison Wesley/Pearson Education Inc., 2008). The section discusses, at least in part, one possible technical solution: standardizing software itself. Software manufacturing remains deeply entrenched in an antiquated pre-industrial mindset that insists on building huge portions of software applications from scratch. This is inefficient, prone to error, and ultimately dangerous for the national infrastructure and for all those who rely on it. Standardizing software might just be a future we need to consider.
“A good scientist is a person with original ideas. A good engineer is a person who makes a design that works with as few original ideas as possible. There are no prima donnas in engineering.”
-- Freeman Dyson
“Software engineers frequently violate this rule.”
-- Martyn Thomas, commenting on the above quote .
“There are no prima donnas in engineering; the software industry is full of them,” says Martyn Thomas in “Engineering Judgment” ( Australian Computer Society, 2004 ). The vast majority of software remains handcrafted by extremely talented and innovative individuals who refuse, refuse to use the abysmal code of some other ignoramus developer, thank you very much. This tyranny of genius means that a vast majority of software projects are built from the ground up, employing as many original ideas and implementations within the project as possible, but in the end, duplicating for better or worse what others have done before. It also means the same mistakes are repeated project after project, year after year. Microsoft has been victim of this tyranny, as have Google, Apple, Yahoo!, Sun Microsystems, and just about every software manufacturer in existence.
A nongeneralized approach to software manufacturing requires a maximum of craftsmanship and results in minimal interchangeability; that is, modern software development is more akin to product manufacturing prior to Eli Whitney, where each part within a product was handcrafted and unique. This is a problem. Even if professional standards become the norm in the software industry, software itself remains largely nonstandardized. According to the Eli Whitney Museum and Workshop, Eli Whitney’s muskets, made under contract to the U.S. government in 1809, were the first muskets in the United States to have standardized, interchangeable parts . This revolutionized how products could be made and is a hallmark of the industrial revolution. It is not the hallmark of software manufacturing.
This might seem an odd statement at first. If software is the closest thing to a universal tool we have, and software’s radical malleability allows us to make of it what we will, then one would think that software could be made into standardized and interchangeable parts quite easily. If Eli Whitney could do it with muskets, certainly brighter minds in the 21st century should prevail. As the argument goes, however, requiring software developers to abide by a particular construction standard stifles innovation and restricts creativity and talent. It denies them their craftsmanship. So, although the radical malleability of software means you can do anything you want with software, apparently you cannot standardize it.
If a good engineer is a person who makes a design that works with as few original ideas as possible, software engineers are at a decided disadvantage if there are few prefabricated, interchangeable ideas lying around. The internet is rife with standards and specifications from how computers can talk to each other, to file formats, to how to find web sites; yet, not a single standard addresses software manufacturing. What little guidance is provided regarding software construction is just that, guidance--nonbinding, nonmeasurable guidance that is subject to personal judgments regarding what is best or most convenient. Without standardized, interchangeable software parts, professional standards, such as licensure and certification, can do only so much to reduce weaknesses in software. It also means that software engineers are being limited by their own technology.
We live in a standardized world that is rapidly globalizing. Most industrial nations recognize that effective infrastructure includes, among other things, ready access to capital, energy, transportation, and information. Per Profiles of National Standards-Related Activities (NIST, April 1997), those “other things” are the systems and institutions that support standardization, testing, and quality.It is surprising, then, that with more than 800,000 global standards, none applies to software construction.
Standardization allows a whole new range of functionality that is simply not possible with handmade components. As malleable as software may be, this property comes at the cost of complexity and, at present, lack of interchangeability. Greater complexity makes security harder to accomplish, and without minimally defined boundaries on software’s most exalted property, software manufacturers will repeatedly reinvent the wheel as well as “rediscover” previous defects along with some novel ones. This inflicts a tremendous amount of inefficiency on software production, hindering what software manufacturers could potentially accomplish. Sadly, software engineering is being limited by the very technology it employs, along with the insistence on preserving an antiquated, preindustrial-era craftsmanship mentality.
Because we live in a standardized world, we often take standardization for granted. We should not. The battle for standardization was hard won. In the article “Turn of the Century” ( Wired , January 2002), James Surowiecki states that standardization started with a man by the name of William Sellers in 1864. His cause célèbre : the screw. The similarities between software and screws are interesting.
Surowiecki states that, at the time, screws, nuts, and bolts were custom-made with no guarantee of similarity between manufacturers even in the same city. Likewise, software is largely custom-made with no guarantee of interoperability even between different versions of software. In his speech, “On a Uniform System of Screw Threads,” Sellers noted:
“In this country, no organized attempt has yet been made to establish any system, each manufacturer having adopted whatever his judgment may have dictated as best, or as most convenient for himself. So radical a defect should no longer exist.”
And so in 1864, Sellers set out to correct that defect. He rallied his substantial wealth, considerable technical skills, and enviable political connections to prosecute the first successful standardization battle in history. The conditions under which Sellers took on this fight sound very familiar to today’s. In Sellers’ time, the United States was fast-growing and rapidly industrializing--moving absolutely every relevant form of production to the factory floor. Today, America is quickly globalizing and rapidly “informationalizing”--connecting absolutely everything it can to the internet. In Sellers’ time, the machine-tools industry was the most significant driver of technological innovation, providing the infrastructure that allowed the Industrial Revolution to take off. Today, software fills that role, providing the infrastructure that makes the Information Age possible.
Sellers saw in the screw what others did not, a foundational element of civilization. Without a standardized screw, industrial might was impeded, as was technological progress; parts could not be easily interchanged, interoperability was completely out of the question, and buyers would be bound to a particular manufacturer. If Sellers was focused on the common good, then what was needed was a common standard.
But not everyone shared Sellers’ vision, particularly many within the machinist-tool industry itself. Naysayers saw standardization as a threat to their way of life, as a threat to their craftsmanship. This sounds familiar. Previously in this section, we noted the same hesitancy by software manufacturers toward “software parts”--namely, that standardization of software manufacturing stifles innovation and restricts developer creativity and talent. Standardization at the software level denies software developers their craftsmanship.
In reality, what was true of machinists in Sellers’ day is true for software developers: Anything custom-made has the advantage of locking in customers. In economic terms this means whether someone buys a custom-made lathe, or an operating system composed of custom-made parts, the buyer must come back for repairs, alterations, or upgrades. Even beloved open-source software does not satisfactorily address this issue, given that “open” does not mean “standard.” Open-source software developers must extensively twiddle and whittle their own handmade software parts in order to get them to work with the custom-made parts of their colleagues. Software developers in proprietary ventures developing commercial off-the-shelf software do the same, only behind closed doors. Adopting open or closed source software simply means binding yourself to a given troop of craftsmen, not to a standard of software production.
In short, if screws or software parts become interchangeable, the part becomes more important than the craftsmen; the craftsmen lose their relevancy, and therefore their influence over the market. The same-sized screw can be used in a Honda as easily as it can in a Toyota; it doesn’t matter who put the screw in or even who made the screw, but it does matter that the screw fits, every time.
Members within the machine-tool industry had much to lose should Sellers prove successful. Members within the software industry have no less to lose should software standardization ever become reality. Software developers might fight hard, if not harder than their machinist predecessors, against standardization. A few lessons from Sellers might be helpful to illuminate the path ahead for software standardization.
Surowiecki notes that Sellers recognized that interchangeability and mass production were inevitable. He focused his efforts, therefore, on selecting a screw design that was cheaper, easier, and faster to produce than current screws. This was important. Sellers’ “new economy” was no different than our new economy: Speed, volume, and cost were strategic issues. Any standardized software parts would need to show compelling evidence in this arena.
The article goes on to say that Sellers recognized that momentum is everything in a standards battle. Rapid adoption by just a few key players lends the appearance of inevitability. Before Sellers ever gave his speech, “On a Uniform System of Screw Threads,” he had used his connections to persuade four of the biggest machine shops on the East Coast to adopt his screw. The railroads, rail cars, and eventually the U.S. Navy followed suit. By the close of World War II, Sellers’ screw was accepted by a majority of industries on both sides of the Atlantic.
Finally, setting standards is not without cost or bloodshed. A manufacturing standard, more than any other, threatens the existence of a majority of players within the market. Sellers recognized that the market was best suited for establishing the standard, but the market does not always play along. Other players within the market have vested interests in the status quo.
In truth, software standardization remains far off. The software industry favors craftsmanship far more than any other mode of operation and will undoubtedly provide, as did machinists before them, a plethora of arguments why standardization is unachievable, unattainable, and unreasonable. This is detrimental to everyone. The next great security product will not be a product at all, but a revolution in software production. Perhaps mass production, interchangeability, and automation will eventually radically evolve the production techniques of the software industry to where the machine-tools industry was a hundred years ago. One can only hope for so much.
David Rice is an internationally recognized information security professional and an accomplished visionary. For a decade he has advised, counseled, and defended global information technology networks for government and private industry. Rice has been awarded by the U.S. Department of Defense for “significant contributions” advancing security of critical national infrastructure and global networks.
|
