Until the mid 1980s, the prevailing expectation was that computer software would be bug-free.
After the release of Windows 1.0, people started saying that you couldn’t expect complex software to be bug-free. That attitude incensed me. Software can be as robust and bug-free as people want it to be.The biggest cause of bugs in computer software is the widespread expectation that bugs are an inevitable component of complex computer systems.
A 1986 article in the New Zealand Herald, headed Programming a Messy Business, claimed that writing software today is like building a skyscraper without the help of architects and civil engineers.
The article went on to imply that this situation is a natural consequence of the complex logic inherent in computer software, and that it is difficult to use mathematical tools to avoid errors because logic cannot use the continuous mathematics of materials and engineering.
The greatest advantage of computer logic is that, barring a hardware malfunction, it always works in a totally predictable way. We do not have to deal with the variances and uncertainties of engineering methods and materials.
Our problem is simply one of managing complexity and designing out human error.
The tools for producing error-free systems have been well-developed but little applied. Where they have been applied, the results have been spectacular. In several cases, programming bugs have been reduced to less than one per programmer per year.
So how does one go about producing a bug-free system?
First, choose an appropriate language. Languages differ in their potential for bugs.
A good fourth generation language takes care of database access, screen handling, security checking, transaction logging and other standard operations. This removes the potential for whole classes of bugs, since programs need not be written to perform those functions.
[2012 update: Fourth Generation Languages have fallen out of fashion since 1986, so one must now choose a robust programming language with a good set of libraries.]
Second, design first, just like an engineer does. Make sure you have a sound, workable design before you start coding.
If you discover halfway through a project that your design is not sound, don’t patch it. Throw it away and start again. No matter how much this costs, in the long run the patch will cost more.
Design controlled redundancy into your programs. If you have to perform a precise, intricate calculation also perform a simple, approximate calculation to check the result for reasonableness.
Third, make selective use of program proofs. These mathematical techniques are unmanageably tedious for use on complete systems, but they are highly useful for small, difficult pieces of code.
It is a great feeling to prove a critical piece of code correct, rather than to feel that the code tests all right but may show some defect under extreme conditions.
Fourth, test your program effectively. Techniques for assembling effective test data are widely described in computer literature.
Fifth, control and manage change. Ensure that changes are designed in and not patched on.
With these techniques you can make your software as bug-free as you like?
How far should you go? In practice, it is difficult to make your software more bug-free than the underlying operating system and programming language. After that, it becomes more and more difficult to effectively test your work.
So let us cast aside this expectation that bugs are an unavoidable side-effect of software, and work towards a world where programs that fail are as rare as skyscrapers that collapse.
The New Zealand Herald printed an earlier version of my article in 1986. In 2008, I published another version at Google Knol, which sparked some discussion:
Usman Ismail wrote:
I am guessing they make fairly bug free software for real time applications such as aircraft control etc but there is a cost benefit trade off when writing bug free software for general applications.
It’s not just real time applications and aircraft control software that is “fairly bug free”. I was struck by how much higher quality my accounting software is than, say, some multimedia software.
As you say, it’s a cost-benefit tradeoff. But I suspect the only costs being counted are the immediate ones. There are many longer-term costs which may be discounted because the original developers are not going to be around anymore.
For example, when I started developing software in the 1980s, I made sure that all of it would keep working into the next century. Some of my colleagues didn’t bother, remarking (slightly nervously) that they thought they wouldn’t still be around by then, or the software wouldn’t still be in use. Of course, the millennium did eventually arrive and huge costs were incurred making sure software was updated to handle it correctly.
Jason Smart added:
Firstly, I am hoping that developers of aircraft control software are aiming higher than “fairly bug free”.
I agree with you Roger that a high tolerance of bugs in code is based on an extremely short term cost-benefit analysis, but one that I would posit, ultimately proves fallacious.
It may be compared to shoddy building work or incompetent structural engineering. That work will have to be re-done at far greater cost.
If time is tight, it is better to reign in the scope of your project, concentrating on the essential, high value features and making sure those features perform well and reliably (without bugs).
There are many examples of recent products and software that may appear to be lacking in features initially, but the features they do have work well and attract customers. The missing features are often added later.
Need research? Quezi's researchers can answer your questions at uclue.com