I read in the BMJ the other day* about a case where someone was given a wrong dose because of a miscalculation. I’m sure people get given wrong doses of things all the time; just consider how many millions of people must be in treatment at any time around the world. It would be impossible not to have mistakes.
The point that interested me was how the mistake happened. The patient was a 3-month old baby showing “clinical signs of meningococcal sepsis with petechiae, purpura, and shock” (whatever that might mean). The baby needed a precise concoction of twelve different drugs for treatment.
The dosages were calculated using a spreadsheet template which calculates required dose from weight, age, and so on. In a standard version of Excel it is possible to “lock” particular cells so they cannot be inadvertently edited. For example, you would lock the cell which stores the formula for the calculation, so that you can’t accidentally write over it.
Unfortunately, the software used here wasn’t the full-blown version of Excel or some functional equivalent, but something called PocketExcel. It doesn’t allow locked cells; someone tabbed into the wrong field and overwrote the calculated dose with the baby’s weight. Ouch!
If I remember the article correctly (I don’t subscribe to the BMJ myself…) this all happened at 3.30 in the morning. The person filling it in was no doubt exhausted and extremely stressed. So we can add this instance to the long list of tragedies:
- that occur due to operator fatigue or stress
- and could have been prevented by better tool design
Don Norman’s The Design of Everyday Things is full of situations like this — nuclear power generation and air traffic control, for example — where bad design has allowed exhausted people to make dangerous mistakes. There are plenty more.
Simon Peyton Jones et al mention the similarity between functional programming and the Excel spreadsheet. Each cell in a spreadsheet is keyed off others in the FP style, without dependence on order of evaluation. This allows for the simplest possible model of computation, since a result depends only on the numbers you explicitly plug in to it.
So I would like to extend that comparison slightly and say that what we have here is a demonstration of the dangers of mutable state. If the output-only fields were prevented from being over-written by outside processes (in this case, the user) this problem wouldn’t have happened. Instead, the data-dependency tree which the user expected to hold was no longer there. And a potentially fatal mistake resulted.
* I don’t get to start enough blog posts like that. Alas.