Guide to Insuring Safe Code

Faulty software can no longer be treated as business as usual. Twenty software and safety experts weigh in on what needs to be done: A six-step program for saving lives—and money.

It’s time for a change or two. Or six.

Fundamental problems with the way organizations develop software go, if not ignored, largely unaddressed for far too long. Instead of refusing to employ flawed software, buyers accept bugs, vulnerabilities, corrupt files, system crashes and unpredictable behavior as a cost of business. Weak programming practices mean not just infections of code, but, in the worst cases, revenue- and profit-sapping downtime for corporations, and injuries or even fatalities for humans.

This isn’t to say that some software quality isn’t high. Safety-minded, serious developers have built systems that allow remote-control vehicles to roam the dusty soil of Mars, let telescopes peer through the vastness of space to glimpse the universe’s distant past, and permit jet fighters to stealthily pierce the sky.

Yet everyday life now can’t run without reliable software: in appliances, tools and toys; in pacemakers, infusion pumps and radiation-therapy machines; in factories, power plants and office campuses; in trains, planes and automobiles.

Precisely because of software’s ubiquity–especially in the machines entrusted with people’s lives–“good” is no longer good enough. Only rock-solid software that users can operate without fail and that machines can follow predictably is permissible now.

“There’s a huge amount to be done,” says James Gosling, the Sun Microsystems vice president who was instrumental in the development of the Java software-development product line.

Where to begin?
Baseline gathered the opinions of more than 20 software and safety experts—including Gosling; Bill Joy, former chief scientist at Sun; Herb Krasner, director of the Software Quality Institute (SQI) at the University of Texas; William Guttman, director of the Sustainable Computing Consortium (SCC); Mike Konrad, a senior member of the Software Engineering Institute (SEI); Pradeep Khosla, who heads the Electrical and Computer Engineering department at Carnegie Mellon; Gary McGraw, chief technology officer at Cigital; and Adam Kolawa, chief executive of Parasoft.

Here’s their collective prescription for fixing what ails software development.

 

Too many people building programs lack skills. “Lots of people call themselves software engineers who are not,” says the SQI’s Krasner.

This often means the original design specifications for a software product are inadequate. In the end, these “engineers” can’t assess the risk that the software may not work as intended.

To be a doctor, one must get a college degree, pass medical exams, complete an internships and than take a series of tests to practice in a particular specialty. Accountants, engineers and lawyers also most go through rigorous testing and certification processes.

“That doesn’t happen in software,” Cigital’s McGraw says. “You can declare yourself a software architect and off you go.”

Organizations such as the Institute for Certification of Computing Professionals (ICCP), the Institute of Electrical and Electronics Engineers (IEEE) and the SEI give exams that cover everything from systems development to data management to the various tools and techniques being used by developers.

But, in the end, it’s the companies paying for software that hold the power to demand certification. Today, too few even consider whether the software they buy comes from certified developers.

Next Page: Certify teams, check and recheck, raise the bar.