> She verified everything else and turned on the beam. The machine stopped and the computer screen flashed "Malfunction 54," a mysterious message not even menti

> She verified everything else and turned on the beam. The machine stopped and the computer screen flashed "Malfunction 54," a mysterious message not even mentioned in the Therac-25 manual. > [...] the Therac-25 typically issued up to four error messages a day. It did so by displaying "Malfunction" plus a number, from 1 through 64. No explanation was offered by the computer nor was there any reference to the malfunction codes in the operator's manual. Technicians could, in most cases, bypass the irritating malfunctions simply by pressing the "p" key, for "proceed." Doing so became a matter of habit. Even if you're not doing safety-critical systems, there are many lessons to be learned just from this bit alone. Use human-readable error messages, and make sure they are understandable to the users/operators of your software (not just developers). Including a specific error code is fine -- it can disambiguate similar errors, and make it very easy to do a 'find all' in source to go directly to the offending spot -- but that doesn't help your user. If you're going to allow users to bypass an error, make it deliberate. The best way to do this is debatable, but through years of bad software, users have been trained to dismiss popup messages by pressing OK or 'yes' or 'proceed'. When you show an important error, make sure it's different from informational messages or warnings. Showing users routine warnings and messages is fatiguing and basically just trains them to always press the 'p' key. > According to a computer system's analysis of FDA documents, the computer would not accept new information on a particular phase of treatment (in the case of both Tyler accidents, changing the x-ray mode to electron mode) if the technician made the changes within eight seconds after reaching the end of the prescription data. That's what Malfunction 54 meant. Consider if they had actually tried to show an error message for this (or even document what it meant). Something like "Data on screen does not reflect actual parameters being used. Proceed?" Hopefully at some point during development, someone would question that: "why are we allowing them to proceed in this case?" "If we can detect that is the case, why even show this as an error, instead of just updating the parameters?"