I'd hate to be the engineer that has to deal with these requests. Not even a formal government investigation, just any number of random 3rd party researchers demanding specialized access.
replies(4):
Let me know when devs get stamps that make them legally liable for their decisions. Only then will that honor be applicable to software.
* researchers, because they will have to write data access applications, including a sufficient description of planned safeguards, detailed enough to the point that their university is ready to take a legal liability (and you can imagine how easy this will be), and
* digital service coordinators, because it will take ages for them to process applications from thousands of researchers each requesting a slightly different dataset.
In the end, we need to develop standardized datasets across platforms and to streamline data access processes so that they're safe and efficient.
https://en.wikipedia.org/wiki/Regulation_and_licensure_in_en...
I worked with engineers, what we generally do isn’t engineering by the standards of those engineers.
Which isn’t to say that all software development isn’t.
People writing avionics software and medical software etc are doing what I’d recognise as engineering.
It’s about the process more than anything.
Software in the wild is simply a young field and we aren’t there yet widely.
> Collins Aerospace: Sending text messages to the cockpit with test:test
https://news.ycombinator.com/item?id=45747804
___
Think about how physical engineering orgs are formed. It's a collective of engineers, as it should be. The reason is that zero consequence management abstraction layers cannot exist in a realm with true legal responsibility. Real engineering org structure is written in blood.
I wonder what it will take for software to face that reality. I know that lack of regulation leads to faster everything, and I really do appreciate and love that... but as software continues to eat the world, there will be real consequences eventually, right?
The reason that real engineering liability goes back to at least the Code of Hammurabi is that people got killed by bad decisions and corner cutting.
What will that look like in software history?
Over a couple large public companies, I’ve had to react to a court ruling and stop an account’s actions, work with the CA FTB for document requests, provide account activity for evidence in a case, things like that.
Delete all docs we aren't legally required to retain on topic Y before we get formally subpoena'd. We expect it to be on XXX based on our contact.
This is not a gotcha. My understanding is that bad physical engineering kills people. Is that your understanding as well?
As software takes over more and more control of everything... do you see what I am getting at? Or, not at all?
To be clear, my understanding is that physical professional engineer (PE) legal responsibility is not like the medical ethical code of "do no harm." It's just follow best practices and adopted standards, don't allow test:test login on things like fighter jets, etc. If you fail that, then there may be legal repercussions.
We have allowed software "engineering" to skip all levels of basic responsibility, haven't we?
And I suspect that if you instituted such a system today the results wouldn't be what you like. Failures in complex engineering are typically multiple failures that happen simultaneously when any individual failure would have been non fatal. The bugs are lurking always and when different systems interact in unpredictable ways you get a catastrophic failure. And the way that N systems can interact is on the order of 2^N, so it's impossible to think of everything. Applying the Hammurabi Code to software engineering wouldn't lead to safer software, it would lead to every engineer getting a lottery ticket every time they push a feature, and if the numbers come up you die.
It's not about being perfect, it's about for example "Sr Dev stamped this release, if you can login with test:test after his stamp, he can get sued." Basic stuff, based on industry standards. In physical, these basic standards are not optional. In software, YOLO, role your own auth or crypto? YOLO! ship now you moron! (This is a lesson I am still trying to learn, as it's a good lesson, aside from auth and cryptography.. is there anything else like this? The fact that I have to ask this question is an indictment of the profession.)
I realize how long it would take our entire industry to adjust to a real engineering standard. We will probably need to lose/kill many more lives before doing so, like every other industry/profession has done prior.
Ideally, in the end, the YOLO management mentality will die out on core stuff, as real engineering responsibility takes over. Certain core software orgs will look a lot like your local structural firm: all real engineers, with legal liability up to the top.
But as a reward, you get a shiny stamp with our governments sigil for you to put under your professional judgements, giving them the same significance in a court as legal notices or attestations.