WCP: The Worst Case Principle
My last article, Whatever Happened to the Worst Case?, was a bit of a rant but it promised further articles on the subject. This is the first of these, which does no more than describe what I mean by the “Worst Case Principle”, or WCP. I am using WCP as both a label in the title and as a tag to identify each of the articles. The series is intended to provoke thought, not to be a complete treatise on designing robust software. That would fill a whole book – at least!
In the previous introductory article, I said that it is theoretically possible to design and build perfect software. That is because, unlike the hardware upon which it runs, a software program is immune to degradation over time. If we make no mistakes in designing and implementing the program, it will function perfectly forever. If the entire system (hardware and perfect software) does fail, it’s a hardware problem! Perfection is hard to achieve, of course, but it is still the only worthwhile goal and we are very unlikely to achieve it unless we apply the Worst Case Principle at every stage.
To establish the Worst Cases, at various points in our design, we must answer questions like:
- What is the maximum number of events of type E which can occur within any M milliseconds?
- What is the maximum allowable execution time for this action?
- How much dynamic memory will I need to support the specified maximum number of calls through this PBX, while the system is also performing all other possible concurrent activities?
The Worst Case Principle, though, is all about asking such questions, as a matter of habit. To do that effectively, we must look for trouble all the time. I have often thought that an engineer is an optimist by nature – (s)he has to be! – but a pessimist by training. The necessary attitude of mind can be maintained throughout the design process by adopting Finagle’s Law (more comprehensive than Murphy’s Law) as a silent mantra:
- Anything that can go wrong, will—at the worst possible moment
In other words, when it fails it won’t be during testing, so prevention is much better than attempted cure.
Next time, I’ll take a look at programming defensively against unpredictable timings.