The rocket succumbed to software failures in unneeded “dead code” left over from the Ariane 4 project and compressed schedules that didn’t allow time or money for all the tests programmers wanted to run. "The engineers recommended a $100,000 test platform which they finally got—after the accident," said Jack Ganssle, a software expert and author.

Ganssle is one of several presenters at this week’s Embedded Systems Conference here speaking on lessons to be learned from failures in software engineering.

Among other tips from Ganssle: Make sure to get a good requirements document for any project. In addition, use version control software freely available on the following website. Forty percent of programmers do not use VCS, another major source of project failures.

"We have accumulated 50 years of experience in software engineering, and we don’t seem to use it," said Ganssle in a session entitled "Lessons from Disasters."

"I've been an advocate for a lot of these things for a long time," said Bruce Wenholz, a senior software engineer at Medtronic MiniMed (Northridge, Calif.) who attended Ganssle’s session.

"Full testing is very shallow in the commercial environment," said Wenholz, who as a consultant was once told he could not add anything to a program that controlled an oil field because the system memory for any more code.

"To not have software engineers participate in hardware design leads to an over or under designed situation and either way your system winds up being more expensive than it needs to be," said David Stewart, chief technology officer at Embedded Research Solutions, Inc. Stewart presented a session giving tips about 25 top problems in embedded software development.

When writing code to run across various processors, Stewart recommended programmers pick the two most different CPUs they can find and simultaneously develop code that can run on both. That helps create as much common code as possible and create a simple interface for modules that will support variations for any other CPUs.

"I've seen too many generalizations to support different processors that only make code more complex than it needs to be," Stewart said.

Stewart also recommended programmers don’t try to reuse old code not intended to be reused. Instead they should re-write into tight modules any programs that need to be reused.

"It will cost you if you try to hack existing code into something that is reusable," he said.

Stewart advised engineers to never create if/then/else statements more than two layers deep because they are ambiguous and difficult to understand. Instead programmers should use state machines or UML state charts, he said.

One final tip from Stewart: Write documentation at the same time you write your program. It’s a great way to check the program’s accuracy and help others debug the code in the future. When asked how many programmers fail to write any documentation, a number of hands went up in Stewart’s session amid embarrassed laughter.