London, the capital of my home country England, has a beautiful gothic style lifting bridge built by the Victorians in 1894 that magnificently spans the river Thames. It allows tall ships to access the river upstream by lifting its center sections, which for the first 82 years of its life was powered by huge steam engines.

Steam has since given way to electricity and in 1998 a $3M overhaul was done to upgrade the kit and make it ready for the 21st century. On June 3, 2005, however, everything did not go according to plan and the bridge was stuck open. For 10 hours it remained jammed open while police diverted angry motorists to alternative crossings and the engineers worked against the clock to figure out what had cause the historic monument to malfunction. The reason given when she finally came down was that a software error had caused the problem http://news.bbc.co.uk/1/hi/england/london/4605743.stm. This problem is not an isolated one and was the fourth to occur in three months.

Two thousand years ago the Romans employed an interesting motivational technique: once engineers had finished building a bridge they had to stand under it while the first legion of soldiers marched across. I wonder if the Tower Bridge IT manager wished he'd have done similarly with his programmers when he got hauled before his superiors to answer why one of the main thoroughfares from South to North London was out of action.

One of my very first IT managers used to ban us from using the word "bug" and had us the noun "defect" instead. His wisdom was that the word "bug" was used by a programmer as a way of shirking responsibility, that the problem was of his or her own making and poor workmanship had caused it to occur. The origin of the term is reputed to have arisen from a moth found between the relay terminals of a calculating machine; it's sobering that despite all of the advances in software engineering that have occurred since, problems still occur and, worse than that, are expected and even planned for.

Bugs are expensive to fix, and in Keynesian Economics the value of anything is determined as being the cost of the alternative. What is the cost of errors in code?

In 1996 the European Space Agency rocket Ariane 5 exploded 40 seconds after launch at a cost of $7B due to a straightforward software defect. A data conversion from 64-bit floating point to 16-bit integer threw an exception when the floating point became too large.

The Mars Climate Orbiter in 1998 was destroyed when instead of entering the atmosphere at 90 miles above the surface, it dropped in at around 40 and subsequently burned up. The reason was that some data on the ground was calculated in imperial pounds and reported to the navigation team who thought it was metric newtons.

More recently on January 21, 2004, the NASA Mars Spirit Rover on Mars stopped communicating with Earth. The problem was the file management software that wrote to the rover's flash memory was unable to deal with the volume of data that was occurring at the time and threw an exception fault that crippled the whole unit. Fortunately this was corrected, although by a wing and a prayer - the fix would use the rover's RAM instead of the flash memory, delete a set of in-flight data files no longer needed to reclaim space, reformat the memory and, after three weeks, the Spirit was up and running again.

Crashing rockets is a very visible and costly failure, but it doesn't have to be such a stellar failure when shipping defective code. Is there any such thing as an inexpensive bug, given that any defective piece of software represents bad function?

The problem with defects is that while they occur, the cost of finding and preventing them has a diminishing return, so the approach often taken is that once no more serious defects can be found in a test pass, all that remains must be minor and the programming is complete. The whole act of testing is an odd part of the software engineering process, because the expectation is that bugs will be found and then fixed before the next round of testing occurs. Edsger Dijkstra, one of the grandfathers of modern computing, once wrote: "Testing can only prove the presence of bugs, not their absence."

Testing therefore is not the verification that a program works, but a search for whatever bugs can be found within the time and scope constraints of its execution. In an odd way the whole process of testing sort of vindicates the fact that programming creates malfunctioning code that needs checking and rechecking before it can be shipped.

What troubles me is that we, as software engineers, aren't doing enough to really create error-free software. Does software have to be buggy because of its size and complexity, or do we use that as an excuse to throw more code at an application when we know its existing code base is flawed? Why is a successful test pass measured as one that finds lots of bugs, and not one that gives the program a clean bill of health? Another of Edsger's words of wisdom summarize eloquently; "If debugging is the process of removing bugs, then programming must be the process of putting them in."