Hacker News Reader

Comment by kabouseng | Hacker News Reader

Can Michael Barr be trusted to give an unbiased review. His business is after all embedded software training and coding standards. So magnifying the negative consequences of bad coding practices would play into his business strategy...

(I am not saying hes verdict is biased, I am just stating he has cause to find Toyota guilty).

Furthermore was Toyota's code really of such poor quality relative to the rest of the industry, and relative to the economic realities of the market. I mean it's all good and well to demand aerospace and medical device quality code, but would the average consumer be willing to pay $1000 per LOC for his speed control in his car? I very much doubt it.

View on HN

Michael Barr didn't find Toyota guilty, a court in Oklahoma did. Michael Barr provided testimony to that court.

If you're implying that Michael Barr somehow stretched the truth of what he found, and did so under a legal oath, then I think you're implying that he perjured himself, which is a pretty serious allegation.

Or that he has a conflict of interest which can subtly, and subconsciously, affect ones decisions and conclusions.

Expressing an opinion via the use of concrete but in-this-case-not-actually-demonstrated examples from the code is not normally considered perjury. He believed what he said was true, and had good reasons for that belief.

That doesn't mean it's the truth though. I too read through that looking for something more damning than I found:

The memory wasn't ECC and the code didn't do anything to mitigate that risk, but that doesn't prove that a memory fault occured or even tell us what the likelihood is. Toyota screwed up the stack depth analysis. But AFAICT no stack overflow condition was found. Apparently some other stuff was found (probably with a static analysis tool) on which the article doesn't elaborate.

These are bugs, and certainly don't make me feel good about the system. But they're not a specific finding of fault either.

No I am not saying at all he lied, but the case can be argued various ways. What I am saying is that the court expected from Michael Barr to give expert testimony if the firmware was of "good enough" quality, given the constraints of the market and the risks.

It's easy to overreact after a tragic incident (and I have full sympathy with the families), and to demand more stringent certification, but it comes at a cost as well, the price for the software goes up.

Now lets take a moment to consider how one would go about charging a expert-in-a-field with perjury.

Yet, Barr discovered things that the NASA report didn't.

NASA: "The NESC team examined the software code (more than 280,000 lines) for paths that might initiate such a UA (unintended acceleration), but none were identified."

notice that 1000$/LOC in a car with 1000000 units solds amounts to little more than 11$ (in the case of the article, IIRC: 11000 LOC), so economies of scale do make it perfectly feasable, I guess.

Yes, but it is not just the $ / LOC, it is also the time to market which influences the profitability of a product.

But your point is taken, it might well be feasible to demand aerospace quality code from the automakers.

Improving quality is not the solution. The issue is lack of a proper failsafe system - in this case, a STOP button that physically removes power from the ignition system.

No amount of quality can guarantee the computer cannot fail.

Wargames.

It is important to note here that that many automakers allegedly demand extremely high quality code from themselves. The MISRA C standard [1] is widely used as a guide for high quality embedded code in many industries and was developed by the Motor Industry Software Reliability Association.

[1] http://en.wikipedia.org/wiki/MISRA_C

It's typically been my experience that (within limits) higher quality equals faster production. Can you imagine the debugging time they must burn with 11,000 global variables?

Considering the risks of flying vs. driving, I would argue it makes more sense to demand aerospace quality from cars than it does from airplanes.

Thanks for pointing out the potential bias. I did find myself thinking some of the points were a little exaggerated.

Everyone has come across code which no-one in the company wants to touch because it's too complex. However, that same code may have been in production for decades, proving fit for purpose by example.

That said, I'm not sure I'm entirely against the idea of companies being sued for failing to write sufficient quality code. Could do wonders for the industry!

> However, that same code may have been in production for decades, proving fit for purpose by example.

Until it isn't anymore because one of the critical but undocumented (and possibly even unintended) assumptions no longer applies. See also: Ariane 5. I can easily see that happening in this case - all they'd have to do is shrink the available stack space to free up RAM elsewhere and suddenly critical variables would intermittently get corrupted, possibly only under circumstances that didn't happen in testing.

Witnesses are often paid by the party on behalf of who they are testifying.

Reply on news.ycombinator.com