Whatever Happened to the Worst Case?
I’m dismayed about sloppy attitudes to design. I suspect they’re creeping across from consumer-focused software, where raw average speed is everything and an occasional glitch doesn’t matter. Well, I’m sorry, but as that kind of thinking creeps towards the vehicles I may travel in, or possibly the new nuclear power plant to be commissioned up the road from here, I feel the need to voice my concerns.
Yes, the examples I mention above come from a section of our industry which we can broadly classify as safety-critical and the people working there really do take such matters as robust software very seriously. But all their procedures, documents, standards, reviews and testing will be gradually undermined as their designers and programmers, who ought to consider the worst case at every stage, and are implicitly trusted to do that, increasingly fail to do it. Some engineers seem completely oblivious of the worst-case principle and some seem to have heard about it but decided to ignore it. Those in the former category need to be enlightened, while those in the latter should, to put it kindly, be re-deployed in some other capacity, where they can do no damage.
As a young electronics engineer, I learned very quickly that everything had to be designed with the worst case in mind. This was essential in order to avoid undervoltage, overcurrent, edge races, various other bad things and – ultimately – unreliable products. The calculations were tedious and sometimes it was difficult even to work out what the worst case was! But it all had to be done. Sadly, even a perfect hardware design, perfectly implemented and manufactured (a tall order) will not guarantee a perfectly reliable product because all electronic hardware is subject to electrical noise and physical ageing effects, as well as being vulnerable to damage from various unpredictable causes. Hence the concept of “mean time between failures” (MTBF) commonly used to quantify risk.
With software, we are better placed. For the moment, I will assert, without justification, that it is theoretically possible to design and build a perfect software system. For a non-trivial system, this is not easy, and defects are common, as we know. But these defects are all down to human error. To say such things as “bugs are inevitable”, as if these are malevolent creatures which sneak into our software at night and chew at our code, is disingenuous. We can rise above this. We can and should strive for perfection, while nevertheless acknowledging that getting it right first time might take more time than we initially have available. To have any reasonable chance of achieving perfection, we must, as a matter of course, using all the skills, time and resources we can summon, apply the worst-case principle to our designs. If we do not, we are designing for failure.
This series of articles will be continued. Your contributions, by way of comments, are welcome at any stage.