Some comments on Rich Skrenta’s observation: “I think it’s still a long time before we’ll have building codes for software.”
Building Codes For Software
“I think it’s still a long time before we’ll have building codes for software.”
Rich Skrenta “There is no building code for software”
A building code is a function of the municipality issuing building permits for what is essentially custom construction. Products (and product liability calculations) are driven by tort liability, which is managed by insurance and mechanisms like Underwriters Laboratory testing and certification. It’s also managed at a Federal and state level by legislation
Even though most software licenses have strong limits on any warranty or liability I suspect that we will see both insurance-driven and legislative “design codes” imposed on software as it becomes as woven into the fabric of our lives as wood and sheet rock. The “software content” of not only airplanes but automobiles, power tools, appliances, and many other products is increasing each year.
Traditions are solutions to problems that we forgot we had. Most of the building codes are “rules of thumb” to prevent injury or loss of life, hardwired into legal mechanisms to prevent folks from cutting corners to save money and imposing a downstream risk.
Rich Skrenta is probably right that it will be a while before application software becomes subject to “building codes” but embedded software, and not just for medical implants and airplanes, may transition in a matter of a decade or two.
Two good books that bear at least tangentially on this topic are “How Buildings Learn: What Happens After They are Built” by Stewart Brand and “House” by Tracy Kidder (also author of “Soul of the New Machine“). Kidder offers a number of examples for why it’s hard to develop an innovative design for a house that is actually livable.