- | Home |
- Company |
- Contact |
- News |
- S/ware Eng |
- Standards |
- Academic Support |
- Documents |
- | Requirements |
- Compilers |
- Validation |
- RTOS |
- Analysis |
- Hardware |
- Software |
- Resources |
- Products |
Its not a bug....it's an Error!
By Chris Hills
Feb 2018 
As we discussed in the last newsletter ( click here ), quoting Dijkstra, calling a problem a “bug” hides the fact that it is usually a mistake or an error.
The problem is further masked by tools called “debuggers”. It is high time the software industry faced reality, before the insurance companies and lawyers get involved, and they are starting to be already. Better the software industry adjusts the terminology, and perceptions, ourselves than have The Suits and Spreadsheet Warriors do it for us. Read on at how to remove bugs and have more reliable systems at and spend less money dong it! (btw you can’t buy your way out of this one).
The problem as cited by Michael Barr (https://embeddedgurus.com/barr-code/2018/01/is-it-a-bug-or-an-error/ ) is the first “bug” was actually a real creature that caused an electrical fault. Since then the programmers have called errors and mistakes a “bug”. As we know, statistically at least, all software has “bugs”. It is sort of expected.
No other profession accepts “errors” in its work as a normal occurrence.
Particularly in all other forms of engineering. Jack Ganssle said when he suggested calling “bugs” errors (see http://www.ganssle.com/tem/tem338.html ) the response from some was that they were dyslexic and some of the bugs were due to that…. Well that won’t wash: Spelling mistakes are called spelling errors anyway!
Others said that: if they said “errors” it would make them look bad and their managers would be less sympathetic. Yep! Get used to it.
The courts and public at large are going to get a whole lot less sympathetic to errors (or bugs) in software. Also there is a general move amongst industry commentators and bloggers to say “error” not bug. I suggest you adjust your mind-set now and get ahead of the game.
Ask yourself how you will respond when a manager says “your code contains errors” the problem is magnified if a lawyer asks in front of a judge or jury. The answer is to look at the problem in the cold light of day before someone lese does.
The literature is now referring to errors not bugs See recent blogs, newsletters from industry commentators (Barr, Ganssle, Dijkstra, Humphreys, Chapman etc) This trend will continue and it is better that we practitioners get our heads around it now.
In fact Rod Chapman did a whole presentation on this last week at a conference. He was pushing that we need discipline in the software development.
In reality these bugs are errors and history has shown that it is possible to have a very low error rate for software. The solution is, as pointed out many, many times by the likes of Les Hatton, Rod Chapman, Capers Jones, Michael Barr, Jack Ganssle, Watts Humphey and others, not least myself, is that there is no secret to producing software with a low error rate.
Watts Humphrey said (and Capers Jones book The Economics of SW quality backs this up with the numbers) that if you want to produce software quickly and inexpensively the main win-win strategy is not put the errors in to it to start with. It is also far more cost effective to remove any errors at the point at which they occur or soon after rather than later in the process. High quality software is in fact not only “free” it costs less than poor quality software. History proves this. I myself, have worked on project that came in on time, on budget with very low error rates.
So how do you do that? Well good process, good tools and discipline. It really is that simple. Most of the time in software development is spend removing the errors you have only just put in! Discipline and getting the requirements and design right are a major part of it. Once coding a coding standard, language subset (MISRA-C) and static analysis is essential, then do unit testing. IT requires discipline. After all Software is an engineering discipline.
We, the software industry, have to face reality because the insurance companies, lawyers and courts are starting to do just that. The chances are that at some point you will have to explain your code in court. Excrement always travels downwards and as people try and shift liability to the level below the buck will stop with the programmers. Or at least pause on the programmers.
You may not be doing a critical system that lands you in a criminal court after an accident involving injury or death but you could end up in a civil court where your customer sues you/your company for SW that does not behave as expected. In these IoT days it may be that though your errors your device/system was used as a gateway to another system. The lawyers are a lot less forgiving of errors, especially those that could have been avoided.
The problem is most of the literature and experts will tell you, and the judge/jury, the proven best practice has been around for a couple of decades. Why were you not using it? This is illuminating:-
Some readers expressed the opinion that, since the software was so bad, it must have caused the accident, even if the specific accident theory offered by the plaintiffs falls apart under technical scrutiny (which it does).
One of the comments “I think that it is very interesting that you have a different view that seems more 'legal'/law focused.” The reply was yes….. this was a court case. There will be a lot more of them and the language will be legal.
On a lighter note: A correspondent pointed out that if we call “bugs” errors what do we, in the new regime call, debuggers and debugging. As an interim solution we offer ERTs (Error Removal Tools) This gives us ERTing for the activity. But the serious point behind this is that a controlled development process and the use of appropriate tools will dramatically reduce the problems that turn up in testing and verification.
