Software contains bugs! And we are used to it, but we shouldn’t accept it as a truth!
I am currently working on my PhD thesis (to finish it at last) which is on the subject of the underlying automata of model checking. Model checking is a formal verification technique used to proof that a system is correct, meaning that the system is satisfying given properties. This technique is already used much for software verification in some fields like flight engineering. The software of the Airbus A380 was verified using formal verification methods.
The understanding of formal verification methods is pretty advanced in Science, however the practicability of formal methods to the average programmer is close to zero. A verification of a random program would require like 10-20 times the time it took to write the original code. It took more than a year to a team of specialists to verify part of the A380 software. It will take years before formal methods are build into compilers that will help the programmer with its job to provide a correct program.
Bugs are mistakes, coding errors or design errors, made at some point during the development of the code. We have grown from a point were complaining about bugs in the OS was a daily routine(Windows 95) to a point where we actually are online long enough to notice bugs in software or hardware. Small devices are growing to complete computers (iPhones, GPS,…), and the number of processor is increasing per machine. Asynchronous processes and other requirements of clients make the situation worse, before we can make it any better.
In architecture, an architect designs the plan of a building, the architect has a diploma and he was trained to design plans. After the architect has finished his job, the plan goes to an engineer who is responsible for verifying the plan. He does some calculations about stability, controls the materials used and either gives a go or gives it back to the architect to redesign the plan. But only after the engineer gives his OK, the plan gets reworked to get a plan for the workers, with millimetre precise plans. After those plans are done, the real construction starts, getting on the place where the final building should be standing. During the whole process the architect controls the execution of the work, discusses issues with the workers on fields, try to discover problems before they are in stone…Finally the architect has all the responsibility of the final result.
Sometimes before the final construction, the architect creates some prototypes of the whole house or of some parts, and even the engineer for some special constructions creates prototypes of some parts to verify their properties.
I don’t want to analyse the process of software design, but as a programmer ask yourself if you want to live in your code. Software should be created more like buildings, get a plan first, you are allowed to use prototypes during the plan making phase. However give the plan and not the prototype to an engineer would verifies it. Then start the programming, but as soon as issues arise, stop the process and choose a solution before it’s too late to go back (and the walls around are too high).
Of course for software the comparison with buildings is not true for most of the software, that’s why most software engineers or programmers don’t respect the process. If the program in contrast to a building contains bugs, in general no lives are at risk or only a limited amount of money.
Some famous ‘BUGS’ from Software and other Space:
- Russian Venus Lander (VENERA from wikipedia): The Venera 9 and 10 landers had two cameras each. Only one functioned because the lens covers failed to separate from the second camera on each lander. The design was changed for Venera 11 and 12, but this made the problem worse and all cameras failed on those missions.
and even better:
- Venera 13 and 14 were the only landers on which all cameras worked properly; although unfortunately, the lens cap on Venera 14 landed exactly in the way of the soil compression probe.
- NASA Mars Lander: NASA lost a $125 million Mars orbiter because one engineering team used metric units while another used English units for a key spacecraft operation, ~ cnn.com
- Pentium Bug: The Pentium FDIV bug was a bug in Intel’s original Pentium floating point unit (FPU). Certain floating point division operations performed with these processors would produce incorrect results. According to Intel, there were a few missing entries in the lookup table used by the divide operation algorithm. ~wikipedia.org
