22 minutes! They figured this out and issued a patch in 22 minutes!
Is anyone else just absolutely astounded by how short that response time was?
>That morning, a software bug in an update to the DynamicSource tool caused it to provide seriously undervalued weights for the airplanes.
The real issue question here is how often do they patch this software? Airline control software should not be optimized for feature velocity. It should be optimized for quality and change really slowly.
Ideally, we would have as few updates to this software as possible. We're the pilots informed that the software had updated that morning?
I worry that our increasing comfort with updating constantly broken software bleeds into systems like this that matter for people's lives. Apple has me updating almost weekly because they can't seem to write exploit free software, but my iPhone is not going to kill me. That attitude is not Ok for airplanes.
They didn’t issue a software patch in 22 minutes. It sounds like 22 minutes was the time it took the airline to figure out it was a software bug and tell pilots not to trust the software.
The article says the software bug was fixed in 5 hours, but it’s not clear to me if that was a bug fix or a rollback.
> but my iPhone is not going to kill me. That attitude is not Ok for airplanes.
This is the key point. I imagine the stakeholders here do not think the weight software is that critical, when in fact it could be. This is a common issue with complex systems.
Even though the software does not directly interface with the plane, its outputs are used to make key decisions on takeoff. Normally, there would be a large margin of error allowed, but in this case, due to the desire for max efficiency, the behavior of the aircraft is sensitive to the outputs.
The solutions are to (1) go back to having a large error margin, which of course should be cross-checked for sanity by the pilots, or (2) consider that the software is safety-critical, and should meet the same quality standards as the in-built flight systems.
I'm astounded that it was a problem to begin with. The only reason they managed to fix it so quickly is because they messed it up in the first place and shipped it to production without a stress test.
Further to the ideal, even if they did have to update the software, Alaska would choose to run both old and new concurrently until they're satisfied with the results. If the new code is producing numbers that are wildly off, and that isn't expected, abandon the update.
Is anyone else just absolutely astounded by how short that response time was?
>That morning, a software bug in an update to the DynamicSource tool caused it to provide seriously undervalued weights for the airplanes.
The real issue question here is how often do they patch this software? Airline control software should not be optimized for feature velocity. It should be optimized for quality and change really slowly.
Ideally, we would have as few updates to this software as possible. We're the pilots informed that the software had updated that morning?
I worry that our increasing comfort with updating constantly broken software bleeds into systems like this that matter for people's lives. Apple has me updating almost weekly because they can't seem to write exploit free software, but my iPhone is not going to kill me. That attitude is not Ok for airplanes.