4 ms·

> OEMs are significantly less invested in their developers and the quality of the software they produce than any FAANG. We must be using different FAANG softwa

> OEMs are significantly less invested in their developers and the quality of the software they produce than any FAANG. We must be using different FAANG software because the ones I use on a daily basis are slow and buggy as all hell. The last few versions of macOS/iOS have been atrocious. Every version of CarPlay I've used has bugs. Amazon apps are full of glitches. Compare that to developing engine ECU software which I think is a far more difficult engineering task that the average overpaid UI JavaScript slinger could not handle. You can't just update ECU software every week because you sloppily overlooked something. Unless you're Tesla of course. I don't deny that there are many outstanding, technically excellent engineers at FAANG that deserve every penny they make. But the sad reality is many of them are just TC-chasing posers who got lucky and have subsequently deluded themselves into believing that whatever narrow expertise they now possess is worth far more than it is on the open market.

iso1337 4y ago
I think you’re conflating the UI of Amazon with the more difficult problem of getting a large distributed system to work at scale. Conversely, if your ECU has minor glitches, will you notice? Unless it results in catastrophic failure, you will not even know if happens to result in the occasional 0.1 mpg increase in consumption. And I’m sure VW and the other companies put a lot of resources into software engineering the exhaust emissions defeat workaround.
AlotOfReading 4y ago
Want to know something terrifying? ECU code is often nearly as sloppily written as that JavaScript. They follow MISRA and usually have a couple "QA" teams to catch the most egregious errors of course, but the overall quality is eerily similar to what you'd get if half the team came straight out of a time machine from 1995. I've had to give informational sessions on why boot systems should have redundancy and what undefined behavior is, for example.
- mrguyorama 4y ago
  And yet the ECU shipped with nearly every car for the past few decades almost never fails through millions of cycles. I think all this "ECU code is bad" stuff is just people who don't like the style of the produced code. Are you sure those edge cases aren't accounted for in other ways? Maybe they decided that everything should be "best case" code, and any error just resets the ECU which boots up before the next spark event needs to be triggered. I just cannot square how much people complain about the code in ECUs with how utterly reliable they are. Consider the group that investigated VW cars cheating on emissions. The system was complex and obfuscated, but also powerful, reliable, and configurable by the manufacturer.
  - AlotOfReading 4y ago
    A similar argument was made by Toyota about their systems during the lead-up to the unintended acceleration debacle. I recommend Koopman's talk [1] on the subject for details, but long story short the Toyota ETC was apparently utterly reliable and installed in some of the most popular vehicles on the market at the time. However, detailed investigation of the systems and code behind the few publicized incidents revealed basic system issues like the watchdog failed to detect task crashes, rampant memory safety issues, and even a failure to follow their own internal code guidelines. All of that was manifesting in people's vehicles, but it was only rarely turning lethal and even those cases went mostly unrecognized. Things have improved significantly since the Toyota acceleration issue, in large part because all those details came out. Model-based design is now basically standard for most ECUs, which eliminates large amounts of buggy human-written code. Formal methods tools that don't entirely suck exist. However, most of the issues Koopman points out (especially memory safety) still exist in many places on modern vehicles and all of his points about the issues with relying on testing to surface quality problems remain relevant. [1] https://users.ece.cmu.edu/~koopman/pubs/koopman14_toyota_ua_slides.pdf https://users.ece.cmu.edu/~koopman/pubs/koopman14_toyota_ua_... https://youtu.be/DKHa7rxkvK8 https://youtu.be/DKHa7rxkvK8

iso1337 4y ago

I think you’re conflating the UI of Amazon with the more difficult problem of getting a large distributed system to work at scale. Conversely, if your ECU has minor glitches, will you notice? Unless it results in catastrophic failure, you will not even know if happens to result in the occasional 0.1 mpg increase in consumption. And I’m sure VW and the other companies put a lot of resources into software engineering the exhaust emissions defeat workaround.

AlotOfReading 4y ago

Want to know something terrifying? ECU code is often nearly as sloppily written as that JavaScript. They follow MISRA and usually have a couple "QA" teams to catch the most egregious errors of course, but the overall quality is eerily similar to what you'd get if half the team came straight out of a time machine from 1995. I've had to give informational sessions on why boot systems should have redundancy and what undefined behavior is, for example.

mrguyorama 4y ago
And yet the ECU shipped with nearly every car for the past few decades almost never fails through millions of cycles. I think all this "ECU code is bad" stuff is just people who don't like the style of the produced code. Are you sure those edge cases aren't accounted for in other ways? Maybe they decided that everything should be "best case" code, and any error just resets the ECU which boots up before the next spark event needs to be triggered. I just cannot square how much people complain about the code in ECUs with how utterly reliable they are. Consider the group that investigated VW cars cheating on emissions. The system was complex and obfuscated, but also powerful, reliable, and configurable by the manufacturer.
- AlotOfReading 4y ago
  A similar argument was made by Toyota about their systems during the lead-up to the unintended acceleration debacle. I recommend Koopman's talk [1] on the subject for details, but long story short the Toyota ETC was apparently utterly reliable and installed in some of the most popular vehicles on the market at the time. However, detailed investigation of the systems and code behind the few publicized incidents revealed basic system issues like the watchdog failed to detect task crashes, rampant memory safety issues, and even a failure to follow their own internal code guidelines. All of that was manifesting in people's vehicles, but it was only rarely turning lethal and even those cases went mostly unrecognized. Things have improved significantly since the Toyota acceleration issue, in large part because all those details came out. Model-based design is now basically standard for most ECUs, which eliminates large amounts of buggy human-written code. Formal methods tools that don't entirely suck exist. However, most of the issues Koopman points out (especially memory safety) still exist in many places on modern vehicles and all of his points about the issues with relying on testing to surface quality problems remain relevant. [1] https://users.ece.cmu.edu/~koopman/pubs/koopman14_toyota_ua_slides.pdf https://users.ece.cmu.edu/~koopman/pubs/koopman14_toyota_ua_... https://youtu.be/DKHa7rxkvK8 https://youtu.be/DKHa7rxkvK8