From what I know of the car industry, coding standards are very low. I don't think any car companies would look good if their code was audited by professional software engineers in other fields.
Then you don't know the motor industry very much as it has very strict coding standards like ISO 26262, the code has to be audited internally and by certified 3rd parties with every release to meet the development cycle requirements of the standards.
The industry also has specific coding standard for every language that is used in embedded systems like MISRA-C
https://en.wikipedia.org/wiki/MISRA_C
Today every thing you do with your car from using breaks to deploying air-bags is done through the computer, there's no way in hell that the motor industry would be releasing poor code "intentionally" because it would cost them billions in liabilities.
And you're not familiar with what happened when a 3rd party (Michael Barr) was allowed to FINALLY look inside Toyota's engine code and determine the cause of the "Unintended Acceleration" problem:
"Barr checked the [Toyota] source code against MISRA’s 2004 edition and found 81,514 violations."
The model year 2005 Camry in question from the trial would have been made available in 2004, and the electronic throttle control system was designed prior to 2004 (IIRC, the ETC design was carried forward from the previous model). How does it makes sense to apply MISRA-C:2004 in this case, especially when the Toyota ETC in question was admittedly not designed under MISRA-C:2004 nor prior MISRA-C revisions?
It is inaccurate to claim Michael Barr determined the cause of Toyota's unintended acceleration: he proposed a possible failure mode that was persuasive to a lay jury. His proposed failure mode didn't leave a DTC, so there's no way to actually know if his proposed failure mode actually happened in this case (or in any other).
And 2 of my friends worked for BetterPlace (RIP) and it took years for Nissan to accept the code which had to be rewritten to comply and certified by an external 3rd party.
And that code wasn't even "mission critical" in terms of road safety.
I have seen both very good code and very bad code. Standards are in place for making it good but it really depends the most on who's implementing it and the SW team culture.
The code might even have been outsourced. I'm not trying to disparage outsourced developers, I know what I might do if the user story was something like "Needs to pass emissions when attached to test system."
It shouldn't matter. Another test process should have caught incorrect code. The car should be tested to the specs and the specs should reflect the regulations.
If that's the case, the execs are even more at fault for not having proper controls in place to prevent rogue employees from jeopardizing the entire company.
And, supposing this is true, would you actually be surprised by this? This is a car company, not a CI and code-review obsessed software company in Silicon Valley.
> This is a car company, not a CI and code-review obsessed software company in Silicon Valley.
I read that as:
> This is a company whose products are high-velocity 1500kg chunks of steel zooming around in public, not a company that sells an intangible virtual good/service
---
Yes, I know software is historically poor with car companies, but we should still expect better. Let's not just lower our standards because of cynicism :-)
I found products made by car companies to be in general more reliable than those made by software companies (either in Silicon Valley or not).
I trust my life to my car (software included) every day. I wouldn't do that with any software of my smartphone, not even the OS.
Doesn't it blow your mind that there are no "standards of engineering" or whatever for software? There's no licensure body for software engineers who build software running your car, and therefore no accountability on a personal level.
When an engineer builds a bridge, she has to personally sign off on the bridge, saying it's safe, and is risking not only her professional career, but I think she can also be jailed and held criminally liable if the bridge kills people due to negligence.
It blows my mind, at least, that no such thing exists for software.
The big problem with all those standards, frankly, is that you've gotta pay money to actually evaluate them.
There aren't any guarantees that they'll be useful, that they'll match the modern development processes in your language, that they'll fit your problem domain, etc.
Those standards are there primarily to make the publisher a buck--not to represent the codified wisdom of up-to-date practitioners in a field.
Until we've got a truly open-source standard for people to code against, we should stop wringing our hands about these things.
If you could have perfectly safe software, without requiring individual engineers to be licensed, would that be acceptable to you?
I'm not asking if you think such a thing would be possible or not - I'm asking if you would accept an alternate means of getting what I think we both want.
And a German one and from experience dealing with German companies software isn't regarded I the same light as what they would consider "proper engineering"
Then you don't know the motor industry very much as it has very strict coding standards like ISO 26262, the code has to be audited internally and by certified 3rd parties with every release to meet the development cycle requirements of the standards.
http://www.ldra.com/en/software-quality-test-tools/group/by-....
The industry also has specific coding standard for every language that is used in embedded systems like MISRA-C https://en.wikipedia.org/wiki/MISRA_C
Remember the Toyota code, or at least the review, that was leaked a while back? I don't find it surprising at all that it would be possible to sneak through some stuff that no one knows what it does. And in that kind of environment, people generally don't mess with stuff they don't know what it does, cause they don't know what it'll break.