Michael;

Thanks for posting this, btw. I hope we didn't scare you off by criticizing the content of the article - IMO, all these postings are welcome, even if we disagree with the contents of the link, because it always gets people thinking. (There's only so much you can say about the relative merits of Bic lighters versus oxy-acetylene torches, after all <img src="/images/graemlins/wink.gif" alt="" /> )

The article does make some common-sense points, although I personally believe that most of the examples he gives are not examples of panic at all. (Bad judgement can be caused by many things besides panic - hypoxia, hypothermia, impatience, alcohol- or drug-impairment, time pressure, and "failure to understand the gravity of the situation" spring to mind.)

Poor human factors engineering (HFE) design can cause errors, but not necessarily through panic. (For some very interesting, and very scary, examples of HFE failure, see the book "Set Phasers on Stun", by Steven Casey, if you can find a copy.)

Reverting to ingrained habits in a crisis is not, IMO, an example of "panic".

If you are aware of a HFE "gotcha", there may not be much you can do about it except be aware of it and be prepared to compensate. (The fact that the brake pedal and accelerator are side by side and operated with almost identical actions is a design that's been around for so long, it would be far more dangerous to try to change it, for example. But most people just 'know' whether they're pressing on the accelerator or the brake.)

The main thrust of the article seems to be a call for incorporating HFE into software design, which is a good thing, IMO. But his definition of 'panic' seems to be "whatever I want it to mean". Which is unfortunate.