3 ms·

To be clear: I, personally, am really happy there are strong challengers in the car market. Also, I am speaking solely for myself. The quote: "Model S is desig

• windexh8er 11y ago
  Regarding 1: I am a huge proponent of Kaizen and, what you're probably more after is the influence Demming had on Japanese companies. The interesting part is that if you've studied Demming you'll know he pitched his process to every American manufacturer first - and all of them wrote him off, which, as we all know came back in spades from a quality comparison perspective shortly after. Demming: Quality = Results of Work Efforts / Total Costs. Regarding OTA: It is. But, ignorance is even scarier. Look at any company that embraces CI (continuous improvement). Amazon - how many changes to production do they push a day? Now compare that to a legacy F50 that has process designed to be change averse as they view that as risk in and of itself. This seems to be the viewpoint you're working from through GM and maybe (I'm speculating here) you're influenced by the process internally. Maybe your view is that it's risky because of what you're exposed to? My guess is that given the culture of Telsa - critical software OTA is not taken lightly. Speculation - but they likely have a far more rigorous process for deployment than many others since they've done this from the beginning. If I can suggest reading on this subject I would point you in the direction of Gene Kim's work in this area as he has studied high performing organizations and, in a nutshell, has found that companies that embrace change and do it frequently have less operational problems than those who don't. Risk-averse seems to compound mistakes and, this could very well flow into those hypothesis around practice. The more you do, the better you are and "10k" hours. While I agree accidents can (and will) happen - again I wouldn't put my money that it happens to Tesla first or with any cadence of frequency. Keep in mind Tesla is riding on quality in software - full stop. If they have a problem there, it could be detrimental to the point of failure. This is a good thing for consumers because they're most likely getting a superior product comparatively. And we already know that non-OTA software that has gone out the door in vehicles has caused death and harm. Is it scary that those bits are note able to benefit from a timely OTA update? There are definitely two sides to this coin. And finally... While I know that it's been said quite a bit that "we've done that". I'm not truly sure people are grasping the reality of what Tesla is doing. While I understand others have these features, the Jalopnik short sums up what they've accomplished that, in my opinion, others are definitely lagging behind in - if you haven't watched it definitely do: https://www.youtube.com/watch?v=3yCAZWdqX_Y https://www.youtube.com/watch?v=3yCAZWdqX_Y Again... Even if others are kind-of-sort-of doing this today, the iterations will be across model years. No vendors have the long-term upgradability that Tesla does at this point. Not sure I would trust an American car to change lanes on it's own based on it's situational awareness as shown in the video.
• rkangel 11y ago
  > That being said: OTA update is REALLY FUCKING SCARY for cars. What if someone puts the wrong update in the queue accidentally? (2) OTA update is no more or less scary than any other form of software update, or in fact any other form of mechanical update. Software engineers are generally used to the level of rigour that goes on with their software. If you're a web devloper shipping a commerce application there's an appropriate level of testing and process, because there's only a certian level of reliability you need to hit, and spending more money on that would slow down your development. The way you go about delivering software for medical devices for instance (which we do), is a completely different process with a whole different level of rigour, testing and documentation. Because that's appropriate in that environment. There's a whole lot more documentation and thought that goes into the beam that stops the top of your house from falling down, than goes into the beam that stops your garden shed from falling down. It's no different than software.
  • dognotdog 11y ago
    It's not as simple as that. NASA can update software on the mars rover or interplanetary probes, but that's one device at a time, and the amount of effort put into it is staggering. At the same time, consumer electronics are routinely broken by OTA updates. Cars fall squarely in the middle, high volume and high price. Additionally, failures carry a high risk. Nobody will die if your webshop goes down, but if your car decides to steer into oncoming traffic, well, bummer. The support beam analogy is flawed in the sense that the beams are simply made bigger to ensure they're strong enough even with considerable material defects, but this doesn't work for software, where a single little bug can lead to a catastrophic failure. I am not aware of anything other than cars where such a high number of devices carries such a high risk factor. Certainly doing OTA car updates in a commercial environment is possible, but there is not yet a relatively foolproof way to do it.