5 ms·

because compliance is mostly about documentation. glorified checklists. but checklists work (you might have heard about surgeons leaving medical tools in pati

by pas 4y ago

because compliance is mostly about documentation. glorified checklists. but checklists work (you might have heard about surgeons leaving medical tools in patients, and checklists eliminating this problem, seemingly the dumbest simplest technology, yet it's very powerful compared to the default of nothing) of course the quality of answers matter, but that's on the environment (auditors, regulators, industry best practices, trade groups, client expectations), see the absolute total shambles of the state of IT sec in South Korea, the 1000 year old COBOL systems in finance/insurance, the reservation system in air travel, the sorry state of TLS before LetsEncrypt, SMTP servers (how SPF, DMARC, DKIM and ARC and MTA-STS are all needed to signal that you really prefer TLS, really don't want to be impersonated, you really vouch for forwarded stuff, etc). also there's the BeyondCorp step-up. nobody bothered to really segment the internal network. nowadays the default is zero-trust.

carlmr 4y ago
>but checklists work (you might have heard about surgeons leaving medical tools in patients, and checklists eliminating this problem, seemingly the dumbest simplest technology, yet it's very powerful compared to the default of nothing) These glorified checklists also backfire all the time. With the surgeon it's indeed simple. With software what I see is that certification and process often lessens quality. Why you ask? Well if you need certification, changes become expensive. Because there's a huge tail of documentation and processes to be done. This leads to the perverse incentive to change as little as possible, even though you know it's broken. Boeing knew that they needed to retrain pilots if they changed the 737 MAX airplane too much. So they hacked the hardware, which lead to hacking the software, which lead to omission in the training. All because of the incentive not to change too much lest they need to retrain all pilots. The problem of course is that the retraining is an either or. Either your plane is sufficiently 737 like or not. If not the costs are huge. Especially since the competition's airplane would not need retraining. So the risks of these hacks to make it 737-like enough were weighed against huge costs. The costs were basically not being able to do business at all. Since these planes would be cost prohibitive for the cheap domestic airlines that want them. If the costs were more linear I'm sure this wouldn't have happened. E.g. if you can retrain pilots on only the MCAS system and still not require full recertification.
- acapybara 4y ago
  I'm failing to see how this relates, whatsoever, to the discussion at hand. I don't mean any offense toward you. Just having an incredibly hard time making any sense of what you wrote.
  - bregma 4y ago
    I work for a company that ships safety-certified software. We, or often our customers, have discovered bugs in that software. We do not fix the bugs because one single small bugfix means re-certifying the entire software, a process that takes months of producing proof of matching the safety case plus many more months of updating and approving accompanying documentation and going through an audit. Everything has to be re-touched. We just issue an updated defect list to go with the software and our customers needs to work around the bug. Known unfixed bugs are a fact of life in certified software. Update releases are not. Customers pay a premium for this because they, too, would have to go through the same pain and expense on their side.
    - relaxing 4y ago
      > Known unfixed bugs are a fact of life in certified software. And all the other software.
      - eitally 4y ago
        The difference is that those bugs are certified in one and not the other. In many cases, bugs are known to the SW provider but not disclosed to customers unless they happen upon them. With certified SW, bugs are by default disclosed up front.
    - quanticle 4y ago
      This reminds me of how NASA would never have a Shuttle in flight during the transition from December 31 to January 1, because they were unsure as to whether the shuttle's computers could handle the rollover correctly [1]. Sure, they could have updated the software to make sure that the rollover was handled correctly, but that would have required them to recertify the entire OS running the Shuttle, and it was easier to just plan missions such that the Shuttle was never flying on New Year's Eve. [1]: https://usatoday30.usatoday.com/tech/science/space/2006-11-09-shuttle-computer-glitch_x.htm https://usatoday30.usatoday.com/tech/science/space/2006-11-0...

by pas 4y ago

carlmr 4y ago

>but checklists work (you might have heard about surgeons leaving medical tools in patients, and checklists eliminating this problem, seemingly the dumbest simplest technology, yet it's very powerful compared to the default of nothing) These glorified checklists also backfire all the time. With the surgeon it's indeed simple. With software what I see is that certification and process often lessens quality. Why you ask? Well if you need certification, changes become expensive. Because there's a huge tail of documentation and processes to be done. This leads to the perverse incentive to change as little as possible, even though you know it's broken. Boeing knew that they needed to retrain pilots if they changed the 737 MAX airplane too much. So they hacked the hardware, which lead to hacking the software, which lead to omission in the training. All because of the incentive not to change too much lest they need to retrain all pilots. The problem of course is that the retraining is an either or. Either your plane is sufficiently 737 like or not. If not the costs are huge. Especially since the competition's airplane would not need retraining. So the risks of these hacks to make it 737-like enough were weighed against huge costs. The costs were basically not being able to do business at all. Since these planes would be cost prohibitive for the cheap domestic airlines that want them. If the costs were more linear I'm sure this wouldn't have happened. E.g. if you can retrain pilots on only the MCAS system and still not require full recertification.

acapybara 4y ago
I'm failing to see how this relates, whatsoever, to the discussion at hand. I don't mean any offense toward you. Just having an incredibly hard time making any sense of what you wrote.
- bregma 4y ago
  I work for a company that ships safety-certified software. We, or often our customers, have discovered bugs in that software. We do not fix the bugs because one single small bugfix means re-certifying the entire software, a process that takes months of producing proof of matching the safety case plus many more months of updating and approving accompanying documentation and going through an audit. Everything has to be re-touched. We just issue an updated defect list to go with the software and our customers needs to work around the bug. Known unfixed bugs are a fact of life in certified software. Update releases are not. Customers pay a premium for this because they, too, would have to go through the same pain and expense on their side.
  - relaxing 4y ago
    > Known unfixed bugs are a fact of life in certified software. And all the other software.
    - eitally 4y ago
      The difference is that those bugs are certified in one and not the other. In many cases, bugs are known to the SW provider but not disclosed to customers unless they happen upon them. With certified SW, bugs are by default disclosed up front.
  - quanticle 4y ago
    This reminds me of how NASA would never have a Shuttle in flight during the transition from December 31 to January 1, because they were unsure as to whether the shuttle's computers could handle the rollover correctly [1]. Sure, they could have updated the software to make sure that the rollover was handled correctly, but that would have required them to recertify the entire OS running the Shuttle, and it was easier to just plan missions such that the Shuttle was never flying on New Year's Eve. [1]: https://usatoday30.usatoday.com/tech/science/space/2006-11-09-shuttle-computer-glitch_x.htm https://usatoday30.usatoday.com/tech/science/space/2006-11-0...