16 ms·

Imagine if we did that with software generally. Every time there's a data breach, an agency would investigate with the same thoroughness they do in aviation.

• seanmcdirmid 8y ago
  We would be limited to 20 pieces of software that were very reliable. The problem with software, which makes it so unlike hardware, is that we can use so much of it, the diversity is huge.
  • cryptonector 8y ago
    > ... software, ... unlike hardware, ... Everything is software now. So much firmware (which is software), and so much hardware that cannot run without software. Your refrigerator, your dishwasher, your car, airliners -- the trend is for everything to be software now.
    • nkozyra 8y ago
      Sure, software is everywhere, but the physical properties of hardware are fundamentally different when it comes to QA, risk analysis, general testing.
      • cryptonector 8y ago
        But when all your hardware has firmware, you've lost that advantage.
        • danmaz74 8y ago
          Depends how complex the firmware is.
    • seanmcdirmid 8y ago
      We can build reliable software when we want to. It just has limited scope and/or undergoes more expensive development procedures. It is easy to build a finite state machine for a dishwasher that is fairly reliable. Likewise, consumer jet code that hits safety considerations is heavily tested and audited...and the FAA cares about it whenever it causes a plane to crash, leading to a lot of regulations on how the code is vetted.
• carlivar 8y ago
  No agency needed. Companies do this internally already... right?
  • cptskippy 8y ago
    If and how extensively is culturally driven in an organization. Regulations, regardless of who imposes them, are almost always necessary. The unfortunate thing is that so many regulations are formed without support from the consumers of those regulations which is why they are often backwards or onerous. Gun regulations are a great example of good intentions, bad implementation due in part to ignorance, and industry resistance/interference. Another is PCI which is a self regulation that's often to vague or specific to be useful.
• mruts 8y ago
  Honestly that sounds like hell. I sure as hell didn’t become a developer so I could get thrown in jail for buggy code. Building software is something no one really knows how to do and we are still at the infancy of our field. I don’t think it would be fair to impose the same standards thst real engineers have on such a nascent and choatic field.
  • javagram 8y ago
    One could argue that it’s precisely because there are no standards that the field is so chaotic. I’m not sure what the right balance is - the more standards and compliance there are, the more innovation suffers. On the other hand, without standards or legal responsibility, it makes sense for companies to play fast and loose with security, privacy, and stability in favor of features - a consumer is going to pick a better product based on UX, features, and cost, not based on security they have no way of judging.
  • vonseel 8y ago
    Not sure if I agree that no one really knows how to do it, but yeah, software is not as disciplined as something like civil engineering. And for most things, it doesn’t need to be. For others, their teams operate much more slowly and with more testing and QA - think of a basic web app developer versus someone writing software for Boeing aircraft. The jobs are completely different. For most web app developers, screwing up doesn’t endanger anyone’s life.
    • mruts 8y ago
      I mean we can kind of make software, but it always has bugs and even the biggest companies who have (supposedly) the best developers consistently make products that don’t work very well at all. Software qualiry looks really bad compared to, say, bridges or cars or airplanes.
      • ethbro 8y ago
        Respectfully, I call bullshit on this. We know some very good ways to build reliable software. It's just that most industries can't / don't want to pay the costs associated with doing so. The don't-know / don't-want distinction is functionally irrelevant, but I have a minor tick about it because asserting the former is often used to avoid admitting to the later. Legacy IBM and ATT, for all their cluster%_$^!s, were amazing at engineering reliable systems (software and hardware). Maybe that's not practical nowadays, outside of heavily regulated industries like military / aerospace, because markets have greater numbers of competitors. But we do know how. An accurate and modern truth would probably be "We don't know how to quickly build reliable software at low cost."
• michaelbuckbee 8y ago
  Among the many different things required of the GDPR, CCPA and US state-level data privacy regulations are: 1. Data Breach disclosures 2. Reporting/Public statements if the vulnerability or path that caused the breach has been fixed. Note, this might seem a little weird (like "of course we've fixed the breach!") but often data breaches aren't detected for _months_ after they occur. There's plenty of companies who didn't know they were breached until they were on HaveIBeenPwned. It's not NTSB level thoroughness, but I think it's a healthy start in that direction.
• blobbers 8y ago
  That seems like a pretty good idea. Federally mandated breach investigation when more than X people are compromised. Guidelines are put in place that can be audited.
• mdturnerphys 8y ago
  Your comment reminds me of this article about the Space Shuttle code that I come back to every few years: https://www.fastcompany.com/28121/they-write-right-stuff https://www.fastcompany.com/28121/they-write-right-stuff
  • cheerlessbog 8y ago
    I'm curious whether they applied the same level of scrutiny to the libraries, compilers, and operating system their code used. And firmware.
    • rpeden 8y ago
      All of that probably has to be done in order for the AP-101 to be flight certified. As far as I can recall, they wrote their own operating system and didn't rely on any external libraries. Even when it was new, the AP-101 was part of a family of flight computers that NASA had already been using, and the same is true for the HAL/S compiler used for most of the code. If you want to explore how it all worked, this SE thread contains some great information and also serves as a good launching point for further research: https://space.stackexchange.com/questions/19006/what-operating-systems-were-used-in-the-space-shuttle https://space.stackexchange.com/questions/19006/what-operati...
      • avn2109 8y ago
        People named a computer HAL, and sent it to space??
        • edoceo 8y ago
          One of the tools that helped people and other computers into spaces was named, in part, HAL
  • cmroanirgo 8y ago
    This popped up recently: https://news.ycombinator.com/item?id=19180280 https://news.ycombinator.com/item?id=19180280 It's about a guy doing similar things, with model rocketry. It seems though that the resiliency is all due to field tests/ spectacular failure in the latter. (It doesn't detract from the project at all though).
• deleted 8y ago
  [deleted]
• megaremote 8y ago
  Imagine if we did that with car crashes, which kill 40,000 people every single year in the USA.
  • zamfi 8y ago
    This is a good discussion point: we could do this with car crashes, but I would guess that most causal factors can be summed up as "driver inattention". How would you solve that? The FAA can issue all sorts of regulations requiring rest breaks, fatigue detection, etc. -- be sure you're ready for that level of intervention before you ask for this level of investigation.
    • ACow_Adonis 8y ago
      Car crashes are actually the perfect example, because car fatalities aren't just a function of engineering a safe and sturdy car, and human inattention both can't be eliminated, but also isn't independent of design. For instance, how many people ride in the car? What is the average car trip length? Why and when are people driving? Speed profiles, line of site in both car and environment. Does traffic all flow one way, can a car ever land in incoming traffic if it loses control, are traffic barriers designed to bring an out of control car safely to rest with good line of sight to the accident? Are features keeping drivers alert or distracting them? The difference between lots of fender benders with a bit of panel beating and constant fatalities can come down to multiple causes, many outside of engineering a safe car.
    • post_meridiem 8y ago
      "be sure you're ready for that level of intervention before you ask for this level of investigation." There's no good reason not to, for example, have every car use a breathalyzer to start the engine -- those driving drunk on occasion would protect themselves from DUIs, lives would be saved, etc. Or to implement other, similar deep regulations. But the ideology around cars ("freedom"), vs. planes ("safety"), is too different to allow for such levels of intervention.
      • nradov 8y ago
• cmroanirgo 8y ago
  I like the sentiment, but there are big differences. In software, you can poke/prod away at the running application to get it to do something it shouldn't. To me, this is a bit like yanking wires that you know are important to see what happens to plane in mid flight. Another anecdote I use is to image pulling the steering wheel off a car while someone's driving it. I think modern software testing and security analysis is probably far away better than what the ntsb provides because we've already systems in place to cope with crashes.
• WalterBright 8y ago
  The trick is not to create reliable software. The trick is to create systems that can tolerate complete failure of the software. This is the secret to airplane reliability. (Although they still do their best to make the software reliable, they do not bet lives on its reliability.) Safe Systems from Unreliable Parts https://www.digitalmars.com/articles/b39.html https://www.digitalmars.com/articles/b39.html Designing Safe Software Systems part 2 https://www.digitalmars.com/articles/b40.html https://www.digitalmars.com/articles/b40.html