Tyler Herring asks some interesting questions:

Not likely to help, though vendors will still try. Law doesn't let you indemnify against negligence, even if the customer signs in blood.

They should already.

Ditto.

This is the question I fear most in our "gig economy".

It isn't practical to expect an engineer to assume liability for a company's product, and no engineer in their right mind would ever enter into such a relationship. But nowadays everybody is a subcontractor, and the engineer might be forced to choose between taking on that liability vs. unemployment. And, to put it lightly, companies have LOTS of incentives---and leverage---for distancing themselves from liability.

Uber has confirmed many of my fears regarding this subject.

It's probably already happened.

Software and electronics aren't unique animals as far as the Court is concerned. In our adversarial system, you can't bring a case unless you've suffered harm. Once that harm occurs, the liability is borne by the active agent: the box that caught fire, the car that ran over the pedestrian, etc.

The pedestrian's claim is at the intersection of the car's bumper and their body. The fact that the car's throttle pedal was ignoring the operator is a secondary concern: the car delivered the injury, so the car must make the claimant whole again. The seized throttle pedal was just an accessory to the event, and that knowledge is useful only for the insurance companies to figure out where to recover THEIR losses from later.

Jones asserts that litigation activities have a -9 or larger impact on product quality. That simplification risks mis-reading the cause and effect of his point.

Having observed a couple of malpractice-related proceedings, and in discussions held both before and after same, I've observed that there's nothing quite like actual discovery and/or litigation to sharpen an engineer's senses regarding their personal impact on overall product quality. When done well, the event can be a HUGE positive turning point for an organization---assuming they survive it, that is.

Good managers teach their employees that the whole point of discovery and litigation is to get at the TRUTH behind an event, and that even if the overall finding is unfavorable, having the truth out in the open is always better than attempting to hide it.

"The truth is always the path of least energy." (*)

Shortly thereafter, engineers become paranoid at the thought of standing in front of a jury of grandparents and explaining why their "bad day" caused someone's injury or loss. Those engineers stop producing altogether for a while.

Once an engineer gains confidence that his employer won't throw him under the bus, however, something cool happens: he starts writing code (or designing circuits, etc.) that he WILL stand behind. And in an even more ideal world, he'll start openly and constructively challenging his peers to do likewise so that they can stand behind the system as a whole.
Working while litigation is underway DEFINITELY has a negative impact on a developer's productivity. But afterwards, if the situation is handled well, it can improve the situation by at least the same amount. Don't waste the opportunity.

(*) - I just made that up, but I think that something similar has been said before.

I think Gary Lynch is being a little harsh:

“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.”

Personally I’m amazed at the millions of lines of code on my phone that just work, pretty much perfectly, pretty much of the time.  Just think about the code involved in rendering a font on the screen – there’s font libraries, graphic drivers, windowing systems, right down to trig functions for working out the curves.  The question should be why are we embedded engineers so slow? One answer is that often embedded / safety critical software must be shown to be correct before it is deployed, as it’s hard or impossible to update it in service.  This need will always remain, but is dwarfed by the quantity of software for which that constraint is relaxed.

These are the days of miracles and wonders - Paul Simon
I just can't get no respect - Rodney Dangerfield

How many of us designing microprocessor based products can explain our jobs at a cocktail party? To the average consumer the word "computer" conjures up images of mainframes or PCs. He blithely disregards or is perhaps unaware of the tremendous number of little processors that are such an important part of everyones' daily lives. He wakes up to the sound of a computer-generated alarm, eats a breakfast prepared with a digital microwave, and drives to work in a car with a virtual dashboard. Perhaps a bit fearful of new technology, he'll tell anyone who cares to listen that a pencil is just fine for writing, thank you; computers are just too complicated.

So many products that we take for granted simply couldn't exist without an embedded computer! Thousands owe their lives to sophisticated biomedical instruments like CAT scanners, implanted heart monitors and sonograms. Ships as well as pleasure vessels navigate by LORANs and SATNAVs that tortuously iterate non-linear position equations. State of the art DSP chips in traffic radar detectors attempt to thwart the police, playing a high tech cat and mouse game with the computer in the authority's radar gun. Compact Disk players give perfect sound reproduction using high integration devices that provide error correction and accurate track seeking.

It seems somehow appropriate that, like molecules and bacteria, we disregard computers in our day to day lives. The microprocessor has become part of the underlying fabric of late twentieth century civilization. Our lives are being subtly changed by the incessant information processing that surrounds us.

Microprocessors offer far more than minor conveniences like TV remote control. One ultimately crucial application is reduced consumption of limited natural resources. Smart furnaces use solar input and varying user demands to efficiently maintain comfortable temperatures. Think of it - a fleck of silicon saving mountains of coal! Inexpensive programmable sprinklers make off-peak water use convenient, reducing consumption by turning the faucet off even when forgetful humans are occupied elsewhere. Most industrial processes rely on some sort of computer control to optimize energy use and to meet EPA discharge restrictions. Electric motors are estimated to use some 50% of all electricity produced - cheap motor controllers that net even tiny efficiency improvements can yield huge power savings. Short of whole new technologies that don't yet exist, smart, computationally intense use of resources may offer us the biggest near-term improvements in the environment.

One trick I used last year is to use GCC's '-finstrument-functions' flag which brackets every compiled function with enter/exit function calls. You can write an enter function which tests the amount of stack space left. It's not ideal, but it can save a lot of time. After I did this for the kernel to track down a problem, one of the application engineers applied the idea to a thread-intensive application and found several potential problems.

Another trick is to look for functions where people have mistakenly put large structures or arrays on the stack. Use a tool like 'objdump' to disassemble your program and then a one-line awk or perl script to find the first 'sub...esp' in each function and sort them by size. If you find an irq with 'struct huge', it's just waiting to blow your stack.

I could argue with the accuracy of your second sentence in this piece "Alas, only a tiny fraction of us use any standard religiously."

The sad truth is too many engineers do use standards religiously, i.e., once or twice a year.