Our coronavirus coverage is free for the first 24 hours. Find the latest information at Please consider subscribing or donating.

  1. Archive

Wanted: software that's more reliable

Cars, planes, household appliances and myriad other machines are increasingly relying on software to work. Manufacturers want the flexibility and innovation that programming code can bring.

But software can make machines stop working, something computer manufacturers know all too well.

As the technology for cars and other products advances, manufacturers are seeking to avoid the bugs and system crashes that afflict the computer industry. They know that a car's brakes or a plane's controls may depend on whether their programming code is flawless.

Developing bug-free software is tough, and some engineering experts say it might be impossible. Most software engineers haven't been trained to use disciplined programming methods to eliminate bugs, and they won't learn how to do it overnight, experts say.

Without programming discipline, the complex software making its way into machines such as cars could have tiny errors that could put people's lives in danger.

"It's my fond hope that we get software improvement in place before there's a disaster," said Watts Humphrey, a fellow at Carnegie Mellon University's Software Engineering Institute.

Software already has caused disasters that, thus far, have not inspired a widespread public outcry for better quality.

Authorities partly blamed a poorly programmed ground-based altitude warning system for a Korean Air plane crash in 1997. A federal jury found the design of a database contributed to the crash of an American Airlines jet in 1995 in Colombia.

And NASA's Mars Polar Lander probe was destroyed on its final descent in 1999 when software shut down its engines.

To most people, software bugs represent a nuisance, not a threat. Owners of sophisticated cell phones, for instance, occasionally have to reboot their devices when the software freezes.

It's the price some people are willing to pay for new technology.

Oyediran's car, a BMW 745i, is cutting edge, with an onboard computer called the iDrive that controls hundreds of functions, from the radio to the air conditioning.

When Oyediran gets in his car, he plugs in an odd, rectangular key that stores his personal information. The car immediately adjusts to his preferred seating position and other settings.

"If you're a technology buff, you're going to love the car," said Oyediran, a database administrator from Fort Lee, N.J.

Some drivers weren't initially as enamored with the iDrive. Reviewers in automobile magazines called the software clunky and hard to learn. Some 745i drivers complained of strange flaws, such as an inability to open their trunks from the outside.

Even iDrive enthusiasts admit that it's nearly impossible to manually tune the radio while driving because of the system's complex menus.

BMW has said that early versions of the iDrive are targeted toward technology lovers and serious drivers. And after a few upgrades, most of the original kinks have been worked out, drivers say.

But the lesson remains: Early adopters of new software are likely to suffer through problems.

"It's just part of technology," said Ron McCranie, a 745i owner in Mansfield, Texas. "There's always going to be bugs. It's not going to be perfect."

That's fine when the problem involves adjusting the radio dial.

But what happens when software controls more crucial parts of our lives, such as a car's brakes or even emergency room equipment?

QNX Software Systems Ltd. makes software for both. Bugs might present minor problems, but the Canadian company has found a way to keep devices from crashing completely, product management director Sachin Lawande said.

The key is to make software in a way that allows parts of the code to fail without crashing the whole system, Lawande said. Instead of trying to make an entire operating system work without a single bug _ all but impossible, he said _ QNX concentrates on a tiny piece of code called a microkernel that must be foolproof.

Outside of the microkernel, "Any piece of code cannot be trusted not to fail," Lawande said. Glitches might happen, but they'll be nonfatal errors easily caught in testing, he said.

Testing is part of the problem, said Humphrey of Carnegie-Mellon. Softwaremakers test their products based on assumptions of how the products will be used, he said. Bugs happen when software is asked to do something programmers didn't foresee.

As software grows more complex, with more interlocking parts and different systems exchanging information, there are more variables to test, he said. That increases the chances of overlooking a bug.

The software industry, only about 40 to 50 years old, was built and pioneered by smart people who didn't follow the rules. Programmers are trained in that culture, and the best of them consider themselves artists or three-point shooters who win the game at the last minute.

That culture has produced major advances in technology, but it's also a breeding ground for bugs, Humphrey said.

"Software is the least disciplined thing in the world," Humphrey said. "The personal practices are all different, even though they're doing essentially the same thing."

There is hope that times have changed. Microsoft Corp., one of the companies most reviled for its bugs because of its software's ubiquity, has in the past year tried to retrain its programmers in a directive called Trustworthy Computing. Other software companies say they're taking similar measures.

Companies outside the computer world, such as automakers, may make the software industry better by demanding a higher level of quality as customers, some experts say.

"The automotive industry is very reliability-oriented, unlike the computer industry in its early days," said Walden Rhines, chief executive of Mentor Graphics Corp., which makes software and hardware design systems.

Automakers "want super-reliable embedded software, designed-in redundancy and error-checking to make sure anomalous events don't occur when the 50 microcontrollers boot when you start your car or thereafter," he said. "It is in the mainstream of what automotive companies are good at doing."

Humphrey and his colleagues at Carnegie-Mellon have developed standard methods to write software code and to test it for errors, and many softwaremakers are trying to adopt the methods.

The Carnegie-Mellon style calls for programmers to participate more actively in project planning to set realistic expectations for themselves. Many programmers like it once they've tried it, Humphrey said.

But it's difficult to change an industry that is very set in its ways.

"We've bred a bunch of people from teenagers all the way up to people in their 40s who haven't had a proper education in software engineering," said Peter Neumann, principal scientist at SRI International's Computer Science Laboratory.

"People that are doing software development are flaky in many cases. They certainly haven't been exposed to some of the horror stories we're looking at," Neumann said. Writing software correctly "takes an awareness, an enlightenment, if you will, that is very uncommon, the same way that common sense is very uncommon."

If the industry doesn't police itself for quality, the government may get involved, Humphrey said.

"Most things that affect public safety have rather stringent government regulations," he said. "If we have a big disaster, we're going to get rather stringent regulations on software."

There is another way to avoid software bugs: leaving software out of the picture. If a household appliance such as a toaster has worked perfectly well for decades, there's probably no need to add software to it, Neumann said.

But Neumann conceded, and other experts agree, that software has the ability to do good things. The old mechanical world was never fail-safe, either, said Mitchell Fonberg, a BMW 745i owner in Dallas.

Even if software controls something as crucial as a car's brakes, "There's always going to be a glitch," Fonberg said. "But it's still going to be more dependable than a human making a decision to brake."