Note this article for your discussion on engineering 'malpractice':
www.asee.org/documents/sections/midwest/2006/Engineering_Malpractice.pdf
Which is similar to words of my employer's legal counsel, where the basis of a civil tort would be negligence + lost opportunity + damages, such that at least two of the three will mean trouble in court, and all three is where your insurance company demands that you seek a pre-trial settlement. And recent changes to product safety assessment regulations contribute to product complexity and increase corporate risk. For example, EU's new Low Voltage Directive requires a formal risk assessment where conditions of 'foreseeable misuse' must be part of your analysis and design intent. So what may be reasonable for an engineering action takes a back seat to what is "reasonable behavior" for any end-use operator. Have seen more than one tort action where the root cause was not equipment failure, but where a 'trained' operator ignored both electrical and written warnings and bad things happened after equipment was forced to continue operations.

Operator misconduct, at least for my industry segment, has not been indicated as a common root-cause failure of equipment. But this will change. The current evolution of product administrative law and product safety standards are pushing any level of a bad outcome resulting from willful human misconduct to be considered equipment failure. Legal risk is a significant contributor to investment in process automation and/or robotics - eliminating the human decision-maker always reduces risk. All hail to the AI overlords...

Your treatise on software malpractice touched a nerve. I have been designing the stuff for over 30 years and I see a trend away from my definition of quality.

A few years ago I switched to a new microprocessor and a new IDE. Contributors to the IDE user forum (which replaced the technical support department) advised me to always download and install the latest updates. When I wrote in that I couldn't view the special function registers on the debugger, they asked for my version number and said that my version was so old it didn't support viewing the processor's registers. When I replied I had checked the box to notify me of new releases, they said my version was so old that the auto-notification feature didn't work either!

My office mate was a contractor who trolled for new business on his smart phone, which locked up every 2 or 3 calls. I asked whether he didn't find that excessive, but he didn't. One day it disconnected him from a probable job offer from an unknown source. Even after it cost him a job offer, he refused to consider chucking it for a better phone!

We hired a new programmer and he asked me what I used for a bug tracker. I said I had a requirements management system and it could handle the bugs, too. I later learned he expected to deal with dozens to hundreds of bug reports at the same time. In my world view, if I have 2 simultaneous live bugs, it's a bad day.

But with the passage of time, I have been finding fewer and fewer people who understand me when I try to explain this standard. They seem to be trained to believe you have to ship product with known defects and deal with them only when somebody complains. I fear when you and I are gone, no one will remember that it used to be different.

Just an interesting side thought on your piece about software malpractice... If it ever came to be, in a legal sense, I do sort of wonder what kind of change it would drive in the industry at large.

1) Increase in indemnity clauses in contracts or product documents (manuals, terms of use, etc.)?
2) Contractors or software houses getting insurance for malpractice?
3) Increase in code audits/code reviews? Having to document these for legal purposes?
4) Relaxation of project timelines to allow for audits and software cleanup?
5) Does the individual developer assume the liability? His or her boss? The company at large?
6) Does this drive adoption of newer methodologies seen to be "newest best practices"?
7) What the end effect any of the above may have on total number of bugs in the first shipped version?
8) What the first inevitable really, really big court case to establish case law on this would be.
9) What if the end software package has to be signed off on by a Licensed Professional Engineer?
10) How would this affect the "small start-ups" in the software industry?

It does make one wonder.

Last week I took my cat into the vets for some surgery. They asked me if I wanted them to perform various tests before doing the surgery.

Me: "Will it change what you do?"

Them: "No"  (apart from jack up the bill and give me a pretty printout with stats).

Me: "Then the tests are pointless. No tests."

In some cases I feel that way with gazintas and gazoutas. Like Ada exceptions et al, they're great during development and testing, but what do you do with them in a real live system?

Erlang has a "let it crash" policy. That might be acceptable in some conditions, but is overkill in others. Do you set the whole car on fire because you find a little scratch? Do you send the pilot to his death knowing that  exception 17 was triggered on variable xx1130?

One of the most dramatic examples of checking being too draconian is the Ariane rocket destruction. Ada threw an exception when a value went out of bounds. That variable was not even required at the time. It could have been a random generated value and it would not have mattered. But Ada cared so much about one little variable that it blew up the rocket. That would never have happened with C (sure other problems might have).

I've seen systems fail because ancillary logging features failed. A temperature sensor came loose giving wild temperature readings, instead of just ignoring it, an assert fired in the backlight driver and the system crashed.

The other chestnut is a write to a logging system failing, so the whole system is killed by an assert. That's often a terminal problem since the file system is typically not fixed by a reset.

I've been reading some of Nancy Leveson's "Safeware" again (I read it about once a year). She relates a few aircraft crashes where the the plane software was deliberately crashed (assert/exception/whatever) because the software writers never expected the situation to arise. The plane would have recovered except that the gazinta gazouta checks crashed the plane.

So whatever you do with gazinta and gazoutas make sure you back them with a policy that is fitting the conditions you're using them in!

I just skimmed today's Embedded Muse and got a blast from the past: gazintas.

This doesn't relate to the topic in the Muse but HPL, the language I contributed to that ran on the HP9825 used the "gazinta" () as an assignment operator instead of the equals sign. That removed the ambiguity of the assignment function from the comparison function. There was a gazinta key on the keyboard. On the original Chicklet keyboard, it was usually one of the two keys that wore out first.

Here's a photo of the "new" keyboard based on real Cherry mechanical switches. The gazinta key is to the left of the "7" key on the number pad. (The inset to the right shows the key more clearly):