4 ms·

I agree, but is there a way that could happen without slowing the process to a crawl? Depending on what’s involved it could easily push the gap between updates

I agree, but is there a way that could happen without slowing the process to a crawl? Depending on what’s involved it could easily push the gap between updates from months to years.

toomuchtodo 8y ago
This is a feature, not a bug, and should be expected in life critical systems. Would you want Boeing to push updates out as frequently as Tesla does with the same sparse release notes Tesla provides (“bug fixes”) when safety system functionality is modified? Disclaimer: I own a Model S
- anth_anm 8y ago
  Imagine if Boeing got away with just pushing a software update to the 737 MAX8 and saying "it's fixed now".
  - CamperBob2 8y ago
    Well, it might have prevented the second crash if they had treated the matter with a bit more urgency. Depends on whether the two incidents really had a common cause, which is looking like the case. Of course it's also looking like they should have grounded the fleet after the first crash, given the history of the aircraft prior to its last flight.
    - deleted 8y ago
      [deleted]
- CamperBob2 8y ago
  This argument would be a bit different if we were losing 30,000 people a year in airliner crashes, instead of approximately zero.
  - toomuchtodo 8y ago
    You can still save lives with automotive safety systems and not have a dumpster fire of an SDLC process. There is a spectrum between one firmware update a year and "f* it we'll do it live".
    - CamperBob2 8y ago
      I think a big step forward would be addressing something you mentioned earlier, with respect to documenting what changed in a given update. "Bug fixes" doesn't belong in a Spotify changelog, much less one for a product made by Boeing or Tesla. It almost seems like a right-to-repair issue, where manufacturers are going out of their way to avoid documenting how their products actually work for fear of losing control over them or of disclosing details that a competitor or patent holder might find useful. There definitely needs to be a strong regulatory response to that kind of behavior on the manufacturer's part when it comes to safety-critical updates, or even updates that might conceivably impact safety of life. Which, in the airplane business, is basically all of them.
      - toomuchtodo 8y ago
        You make excellent points, and I think the unfortunate answer is regulation will be required.
notfromhere 8y ago
do you want faster updates or a machine that doesn't inadvertently kill you? because for life-critical systems you really can't do both
deleted 8y ago
[deleted]
CharlesColeman 8y ago
> I agree, but is there a way that could happen without slowing the process to a crawl? I don't see why a more rigorous release process would slow progress down at all. All the iterations that lead to progress should be done on test vehicles, not customer vehicles. "Move fast and break things" is a development model that should only be applied to low-importance, low-risk systems. Most software development work occurs on such systems, and I think that narrows the perspective of the software development community as a whole.
v_lisivka 8y ago
Autopilot can automatically record all incidents and then upload them to Tesla, with obfuscation and by user permit, to improve autopilot software. Tight feedback loop is much better for AI, IMHO.

I agree, but is there a way that could happen without slowing the process to a crawl? Depending on what’s involved it could easily push the gap between updates from months to years.

toomuchtodo 8y ago

This is a feature, not a bug, and should be expected in life critical systems. Would you want Boeing to push updates out as frequently as Tesla does with the same sparse release notes Tesla provides (“bug fixes”) when safety system functionality is modified? Disclaimer: I own a Model S

anth_anm 8y ago
Imagine if Boeing got away with just pushing a software update to the 737 MAX8 and saying "it's fixed now".
- CamperBob2 8y ago
  Well, it might have prevented the second crash if they had treated the matter with a bit more urgency. Depends on whether the two incidents really had a common cause, which is looking like the case. Of course it's also looking like they should have grounded the fleet after the first crash, given the history of the aircraft prior to its last flight.
  - deleted 8y ago
    [deleted]
CamperBob2 8y ago
This argument would be a bit different if we were losing 30,000 people a year in airliner crashes, instead of approximately zero.
- toomuchtodo 8y ago
  You can still save lives with automotive safety systems and not have a dumpster fire of an SDLC process. There is a spectrum between one firmware update a year and "f* it we'll do it live".
  - CamperBob2 8y ago
    I think a big step forward would be addressing something you mentioned earlier, with respect to documenting what changed in a given update. "Bug fixes" doesn't belong in a Spotify changelog, much less one for a product made by Boeing or Tesla. It almost seems like a right-to-repair issue, where manufacturers are going out of their way to avoid documenting how their products actually work for fear of losing control over them or of disclosing details that a competitor or patent holder might find useful. There definitely needs to be a strong regulatory response to that kind of behavior on the manufacturer's part when it comes to safety-critical updates, or even updates that might conceivably impact safety of life. Which, in the airplane business, is basically all of them.
    - toomuchtodo 8y ago
      You make excellent points, and I think the unfortunate answer is regulation will be required.

notfromhere 8y ago

do you want faster updates or a machine that doesn't inadvertently kill you? because for life-critical systems you really can't do both

deleted 8y ago

[deleted]

CharlesColeman 8y ago

> I agree, but is there a way that could happen without slowing the process to a crawl? I don't see why a more rigorous release process would slow progress down at all. All the iterations that lead to progress should be done on test vehicles, not customer vehicles. "Move fast and break things" is a development model that should only be applied to low-importance, low-risk systems. Most software development work occurs on such systems, and I think that narrows the perspective of the software development community as a whole.

v_lisivka 8y ago

Autopilot can automatically record all incidents and then upload them to Tesla, with obfuscation and by user permit, to improve autopilot software. Tight feedback loop is much better for AI, IMHO.