• Introduction
• Myth 1: The cost of computers is lower than that of analog or electromechanical devices.
• Myth 2: Software is easy to change.
• Myth 3: Computers provide greater reliability than the devices they replace.
• Myth 4: Increasing software reliability will increase safety.
• Myth 5: Testing software or "proving" software correct can remove all the errors.
• Myth 6: Reusing software increases safety.
• Summary

One of the best books to come out in recent years is Safeware: System Safety and Computers by Nancy G. Leveson. Although this book is written from the perspective of software development for the embedded systems and controls industry, there are valuable lessons here for standard business application developers as well. We are particularly fond of Leveson's list of 'Software Myths.' In this article, we will list these myths, and discuss their applicability to standard business application development.

The lesson here is that despite all the advances in software and hardware, we still need to be at least a little careful about what we choose to automate. This is particularly true since all of the 'low hanging fruit' has already been harvested. All the really big benefits of automation were reaped in the first wave of software development when things like bookkeeping, billing and accounting were mechanized. Today, we need to be careful about replacing $5 paper solutions with $500 computerized solutions.

As Leveson points out, it is true that software does not fail in the traditional sense. There are no limits to how many times a given piece of code can be executed before it 'wears out'. In any event, the simple expression of this myth is that our general ledgers are still not perfectly accurate, even though they have been computerized. Back in the days of manual accounting systems, human error was a fact of life. Now, we have software error as well.

It is possible for software to be perfectly reliable and still do the wrong thing. One of the things we emphasize in our process maturity consulting is the importance of identifying defects as early as possible in the product lifecycle. Finding and repairing a defect in a requirement is approximately ten times more economical than finding the defect during coding. Beyond that, defects that escape the requirements process can become part of the software itself.

Certainly reusing software can increase reliability. But the trouble goes back to the requirements issues discussed under myth #5. Despite everyone's best efforts, the completely 'generic' modules that are written almost certainly have some degree of context dependency. Put those same modules in a different context, and unpredictable things can happen.

This myth is particularly troubling because of the false sense of security that code re-use can create. Code re-use is a very powerful tool that can yield dramatic improvement in development efficiency, but it still requires analysis to determine its suitability and testing to determine if it worked.

As was mentioned in the introduction, most of the ideas in this article came from Safeware by Nancy Leveson. We direct the interested reader to that book for more thoughts on this subject.

We also conclude that most of these thoughts fall into the "there is no magic bullet" category. By this we mean that technological solutions always bring their attendant problems with them. There are no technological solutions that can be introduced that will overcome process immaturity. Process maturity continues to represent the best option for development organizations that are seeking to improve their overall effectiveness.