3 ms·

This really isn't about input. Whether it comes from outside or produce inside the application, the reality is that everything can have bugs. A correct input ca

This really isn't about input. Whether it comes from outside or produce inside the application, the reality is that everything can have bugs. A correct input can cause a buggy application to fail. So while verifying input is obviously an important step, it is not even a beginning if you are really looking to building reliable software. What really is the heart of the matter is for the entire thing to be allowed to crash due to a problem with single transaction. What you really want to do is to have firewalls. For example, you want a separate module that runs individual transactions and a separate shell that orchestrates everything but has no or very limited contact with the individual transactions. As bad as giving up on processing a single aircraft is, allowing the problem to cascade to entire system is way worse. What's even more tragic about this monumental waste of resources is that the knowledge about how to do all of this is readily available. The aerospace and automotive industry have very high development standards along with people you can hire who know those standards and how to use them to write reliable software.

jacquesm 3y ago
Yes, there are multiple problems here that interplay in a really bad way and that's one of them. But the input processing/validation step is the first point of contact with that particular flight plan and it should have never progressed beyond that state. It all hinges on a whole bunch of assumptions and each and every one of those should be dealt with structurally rather than by patching things over. Just from reading TFA I see a very long list of things that would need attention. Quick recap: - validate all input - ensure the system can never stall on any one record - the system will occasionally come across malformed input which needs a process - it won't be immediately clear whether the system or the input is at fault, which needs a process - testing will need to take these scenarios into account - negative tests will need to be created (such as: purposefully malformed input) - attempts should be made to force the system into undefined states using malformed and well formed input - a supervisor mechanism needs to be built into the system that checks overall system health And probably many more besides. But this is what I gather from the article is what they'll need at a minimum. Typically once you start digging into what it would take to implement any of these you'll run into new things that also need fixing. As for the last bit of your comment: I'm quite sure that those standards were in play for this particular piece of software, the question is whether or not they were properly applied and even then there are no guarantees against mistakes, they can and do happen. All that those standards manage to do is to reduce their frequency by catching the bulk of them. But some do slip through, and always will. Perfect software never is.
- deleted 3y ago
  [deleted]

jacquesm 3y ago

Yes, there are multiple problems here that interplay in a really bad way and that's one of them. But the input processing/validation step is the first point of contact with that particular flight plan and it should have never progressed beyond that state. It all hinges on a whole bunch of assumptions and each and every one of those should be dealt with structurally rather than by patching things over. Just from reading TFA I see a very long list of things that would need attention. Quick recap: - validate all input - ensure the system can never stall on any one record - the system will occasionally come across malformed input which needs a process - it won't be immediately clear whether the system or the input is at fault, which needs a process - testing will need to take these scenarios into account - negative tests will need to be created (such as: purposefully malformed input) - attempts should be made to force the system into undefined states using malformed and well formed input - a supervisor mechanism needs to be built into the system that checks overall system health And probably many more besides. But this is what I gather from the article is what they'll need at a minimum. Typically once you start digging into what it would take to implement any of these you'll run into new things that also need fixing. As for the last bit of your comment: I'm quite sure that those standards were in play for this particular piece of software, the question is whether or not they were properly applied and even then there are no guarantees against mistakes, they can and do happen. All that those standards manage to do is to reduce their frequency by catching the bulk of them. But some do slip through, and always will. Perfect software never is.

deleted 3y ago
[deleted]