6 ms·

I'm of the opposite opinion. The industry is awash in newbies with senior titles being put on software projects where they are directly responsible for safety,

I'm of the opposite opinion. The industry is awash in newbies with senior titles being put on software projects where they are directly responsible for safety, privacy, health care, etc. Right now when software kills people, they chock it up to a system or hardware failure. In the next decade we will hear more about software bugs killing people, outing them, bankrupting them, overturning governments, hobbling armies, and then we'll have to reckon with why regulated titles exist.

Gigachad 4y ago
No one can agree on what should actually be part of the regulation though. It would end up becoming a box checking exercise like security is where complying with requirements and actually being secure are unrelated. Can you imagine if governments regulated something like if your code touches important data, it must either be written in a verified safe language like Rust? How would people feel about that? Regular engineering is a lot easier to regulate because there are a lot of agreeable rules like “fire escape stairs need to be x cm wide with a step depth of z cm. And there is no situational context that needs to be taken in to account. While all programming best practices are vague helpers that should be discarded as soon as they aren’t helping.
- vineyardmike 4y ago
  > Can you imagine if governments regulated something like if your code touches important data, it must either be written in a verified safe language like Rust? How would people feel about that? Considering the history of memory-not-safe bugs and exploits and the efforts to rewrite critical things in rust due to memory safety I imagine this could be a real debate. In the “real world” we have requirements for materials and tools and practices because some are less safe. Imagine if a building was welded with a technique that could fail? We’d legislate away from that technique. Even when people say “there are ways to make unsafe welding ‘safe enough’”. Software could maybe use some rigor even if it means “go slow and don’t break things”.
  - Gigachad 4y ago
    I think regulating against unsafe languages like C might be one of the few agreeable rules. But I'd be concerned it would end up regulating in a mountain of useless design patterns and bloat which could freeze the state of software development. If these laws came out 20 years ago I'd imagine we'd still all be using Java with UML diagrams legally required.
- light_hue_1 4y ago
  Software isn't all that different. There are plenty of things that the government could mandate. For example, there could be coverage requirements. Want to work on software that determines if a bridge will be safe or not? Then you need 100% branch coverage. You gave as an example something from a building code. That's just a test case. There's no reason why for common types of software (CAD, fluid simulators) we could not have repositories of test cases that you must pass to within some tolerance. You could even make it adverserial and let people suggest new test cases. Or we could decide on some reference implementation that you must either match, or exceed. So if you design CAD software, on any input that both your CAD software can handle that this reference implementation can too, you must match. That's more of a programmatic open ended test case. If we're worried about discrimination, there's no reason why the the government couldn't publish a set of typical profiles (fake names, locations, credit scores, etc.) that your algorithm must treat equally to within some tolerance. etc. We can totally regulate software like we do other engineering disciplines. If we wanted to and thought that the resulting increase in cost and slowdown in development is important enough.
  - Gigachad 4y ago
    Code coverage is not a very useful metric. It’s very easy to have 100% coverage without really testing anything. It works as a vague measure of test quality as long as none of the developers care about the value. As soon as they start making the coverage stat a goal itself, it becomes useless.
  - kortilla 4y ago
    Code coverage tells you code was executed, not tested. What a worthless metric.
  - pbourke 4y ago
    I think the regulation should happen upstream of the software. Code that goes in a medical device should be subject to different levels of rigor than code that goes into a free to play mobile game. To use your example of CAD software, certainly the system used to design a bridge should be built differently than the one used to make inputs to a consumer level 3D printer. There’s no such thing as a “casual” bridge or a “good enough” pacemaker, but that analogy holds in the software industry. Software’s infinite flexibility means that it should be regulated within its context of use.
- tbrownaw 4y ago
  Software - or computer systems - are regulated in cases where it matters. Airplane stuff is regulated by the FAA. Medical devices are regulated by the FDA. One of those "sudden acceleration" suits went against the mfg partly because they hadn't followed proper coding standards. Credit card stuff is regulated by the industry rather than government under the pci-dss standard. Cloud providers advertise as being hipaa compliant, so that set of rules must have a technical component.
  - throwaway787544 4y ago
    I have worked on medical devices and HIPAA controlled data. I have seen PhDs leading their field work next to a college grad who didn't even have a CS degree work on the same code. Trust me: you do not want to be operated on by a robot made by the kid out of college.
- goodpoint 4y ago
  > ... governments regulated something like if your code touches important data, it must either be written in a verified safe language like Rust? You are making a strawman. Having a professional body that people could be ejected from makes a lot of sense in case of egregious misconduct and malice. In events like Boeing 747 MAX, the car emission defeat device, backdoors & spyware, engineers should have safe channels to report wrongdoing, and get legal protection, but also face expulsion if they say nothing and.
kabdib 4y ago
I can guarantee you that "We have to add a bureaucracy to fix all of this" won't actually fix anything. I've seen proposals for regulating software engineers. They've all been transparent and embarrassing land-grabs. One (thankfully) failed effort in California was basically a series of electrical engineering requirements with a little bit of firmware focus, and some idiotic-even-at-the-time development methodology; absolutely useless for the stated purpose.
- wolverine876 4y ago
  > I can guarantee you that "We have to add a bureaucracy to fix all of this" won't actually fix anything. Is that based on some expertise? Many, many other professions - almost all, I think - have professional licensing bodies and they function well. I think we can figure it out too.
  - djbebs 4y ago
    They appear to function well to people who havent got a clue what they're talking about. By and large they are either worthless or actively harmful.
    - wolverine876 4y ago
      Could you provide a basis for that claim? I haven't heard it from the many people I know in those professions, who appear to respect their licensing bodies.
      - kabdib 4y ago
        Don't know about other professions, but all of the proposals I've seen for licensing software engineers have been highly bogus (with lot of irrelevant material) and politically suspect. Here's a great summary: https://cs.stanford.edu/people/eroberts/cs181/projects/2010-11/Licensure/indexba53.html?page_id=2 https://cs.stanford.edu/people/eroberts/cs181/projects/2010-... The observations about the program in Texas mirror what I've seen in similar proposals in California. Namely, tests that concentrate on EE and hardware, with the occasional toss-in of some lifecycle garbage that is not state-of-the-art, nor uncontested in value. The IEEE was behind at least one effort to bring software engineering under its umbrella, which would explain why the state thinks software engineers need to know stuff like Kirchhoff's law and impedance matching. You can go your whole software engineering career without needing that. The proponents don't seem to actually care about what's in the tests, just that they license people, get the fees, and make room for further power grabs. It's pretty unlikely that any improvement in software is going to spring from that kind of arrangement. Licensing is just more "Keep beating the engineers until things improve" with a taste of "Nice career you have here, be a shame if something happened to it, right?" thrown in. We already get that in industry, why invite the government, too?
light_hue_1 4y ago
The problem is that the current regulations around the PEng (Canada) and the PE (US) are nonsense when it comes to software. They don't lead to more accountability. They don't lead to better software. Getting a PEng or a PE is a liability, you're wasting your time as a student instead of learning something useful. To get a PEng or PE you have to take courses in, and pass an exam that covers, topics like power systems. This is a good idea for say a civil or mechanical engineer, since whatever they design will physically interface with all sorts of systems. They need that breadth otherwise accidents will happen. But software engineering is different. The problems with crappy software that lead to deaths, unfairness, etc. have nothing to do with software engineers not understanding power systems. Having people pass such exams contributes nothing to safety. Licensing organizations refuse to change. So they're simply not relevant to software. And as software grows, they're losing their grip on what is already the leading engineering discipline by far. There are more CS graduates (65k) every year than electrical (17k), chemical (8k), mechanical (20k), and civil engineers (15k) combined. Soon there will be more CS grads every year (65k) than all engineers combined (83k).
- ghaff 4y ago
  I don't believe the US even has a PE for software engineering any longer. I think something like 80 people got it after Texas initiated it.
kortilla 4y ago
> Right now when software kills people, they chock it up to a system or hardware failure. Where do you see this happening? 99.99% of software engineers don’t touch safety critical code. There is no reason to regulate them. It’s much better to regulate the safety critical products.
BeetleB 4y ago
> Right now when software kills people, they chock it up to a system or hardware failure. This is sensationalism. Systems involving safety usually have an associated ISO standard. If it's not being followed, there's more at fault than just the SW engineer. In many (all?) states, designing and building something that has safety implications requires a PE license by law - it doesn't matter if it's mostly a SW product or not. The individual engineers don't need the license, but someone in the chain does, and he/she is required to review the work, and it is his/her ass on the line if something goes wrong.

Gigachad 4y ago

No one can agree on what should actually be part of the regulation though. It would end up becoming a box checking exercise like security is where complying with requirements and actually being secure are unrelated. Can you imagine if governments regulated something like if your code touches important data, it must either be written in a verified safe language like Rust? How would people feel about that? Regular engineering is a lot easier to regulate because there are a lot of agreeable rules like “fire escape stairs need to be x cm wide with a step depth of z cm. And there is no situational context that needs to be taken in to account. While all programming best practices are vague helpers that should be discarded as soon as they aren’t helping.

vineyardmike 4y ago
> Can you imagine if governments regulated something like if your code touches important data, it must either be written in a verified safe language like Rust? How would people feel about that? Considering the history of memory-not-safe bugs and exploits and the efforts to rewrite critical things in rust due to memory safety I imagine this could be a real debate. In the “real world” we have requirements for materials and tools and practices because some are less safe. Imagine if a building was welded with a technique that could fail? We’d legislate away from that technique. Even when people say “there are ways to make unsafe welding ‘safe enough’”. Software could maybe use some rigor even if it means “go slow and don’t break things”.
- Gigachad 4y ago
  I think regulating against unsafe languages like C might be one of the few agreeable rules. But I'd be concerned it would end up regulating in a mountain of useless design patterns and bloat which could freeze the state of software development. If these laws came out 20 years ago I'd imagine we'd still all be using Java with UML diagrams legally required.
light_hue_1 4y ago
Software isn't all that different. There are plenty of things that the government could mandate. For example, there could be coverage requirements. Want to work on software that determines if a bridge will be safe or not? Then you need 100% branch coverage. You gave as an example something from a building code. That's just a test case. There's no reason why for common types of software (CAD, fluid simulators) we could not have repositories of test cases that you must pass to within some tolerance. You could even make it adverserial and let people suggest new test cases. Or we could decide on some reference implementation that you must either match, or exceed. So if you design CAD software, on any input that both your CAD software can handle that this reference implementation can too, you must match. That's more of a programmatic open ended test case. If we're worried about discrimination, there's no reason why the the government couldn't publish a set of typical profiles (fake names, locations, credit scores, etc.) that your algorithm must treat equally to within some tolerance. etc. We can totally regulate software like we do other engineering disciplines. If we wanted to and thought that the resulting increase in cost and slowdown in development is important enough.
- Gigachad 4y ago
  Code coverage is not a very useful metric. It’s very easy to have 100% coverage without really testing anything. It works as a vague measure of test quality as long as none of the developers care about the value. As soon as they start making the coverage stat a goal itself, it becomes useless.
- kortilla 4y ago
  Code coverage tells you code was executed, not tested. What a worthless metric.
- pbourke 4y ago
  I think the regulation should happen upstream of the software. Code that goes in a medical device should be subject to different levels of rigor than code that goes into a free to play mobile game. To use your example of CAD software, certainly the system used to design a bridge should be built differently than the one used to make inputs to a consumer level 3D printer. There’s no such thing as a “casual” bridge or a “good enough” pacemaker, but that analogy holds in the software industry. Software’s infinite flexibility means that it should be regulated within its context of use.
tbrownaw 4y ago
Software - or computer systems - are regulated in cases where it matters. Airplane stuff is regulated by the FAA. Medical devices are regulated by the FDA. One of those "sudden acceleration" suits went against the mfg partly because they hadn't followed proper coding standards. Credit card stuff is regulated by the industry rather than government under the pci-dss standard. Cloud providers advertise as being hipaa compliant, so that set of rules must have a technical component.
- throwaway787544 4y ago
  I have worked on medical devices and HIPAA controlled data. I have seen PhDs leading their field work next to a college grad who didn't even have a CS degree work on the same code. Trust me: you do not want to be operated on by a robot made by the kid out of college.
goodpoint 4y ago
> ... governments regulated something like if your code touches important data, it must either be written in a verified safe language like Rust? You are making a strawman. Having a professional body that people could be ejected from makes a lot of sense in case of egregious misconduct and malice. In events like Boeing 747 MAX, the car emission defeat device, backdoors & spyware, engineers should have safe channels to report wrongdoing, and get legal protection, but also face expulsion if they say nothing and.

kabdib 4y ago

I can guarantee you that "We have to add a bureaucracy to fix all of this" won't actually fix anything. I've seen proposals for regulating software engineers. They've all been transparent and embarrassing land-grabs. One (thankfully) failed effort in California was basically a series of electrical engineering requirements with a little bit of firmware focus, and some idiotic-even-at-the-time development methodology; absolutely useless for the stated purpose.

wolverine876 4y ago
> I can guarantee you that "We have to add a bureaucracy to fix all of this" won't actually fix anything. Is that based on some expertise? Many, many other professions - almost all, I think - have professional licensing bodies and they function well. I think we can figure it out too.
- djbebs 4y ago
  They appear to function well to people who havent got a clue what they're talking about. By and large they are either worthless or actively harmful.
  - wolverine876 4y ago
    Could you provide a basis for that claim? I haven't heard it from the many people I know in those professions, who appear to respect their licensing bodies.
    - kabdib 4y ago
      Don't know about other professions, but all of the proposals I've seen for licensing software engineers have been highly bogus (with lot of irrelevant material) and politically suspect. Here's a great summary: https://cs.stanford.edu/people/eroberts/cs181/projects/2010-11/Licensure/indexba53.html?page_id=2 https://cs.stanford.edu/people/eroberts/cs181/projects/2010-... The observations about the program in Texas mirror what I've seen in similar proposals in California. Namely, tests that concentrate on EE and hardware, with the occasional toss-in of some lifecycle garbage that is not state-of-the-art, nor uncontested in value. The IEEE was behind at least one effort to bring software engineering under its umbrella, which would explain why the state thinks software engineers need to know stuff like Kirchhoff's law and impedance matching. You can go your whole software engineering career without needing that. The proponents don't seem to actually care about what's in the tests, just that they license people, get the fees, and make room for further power grabs. It's pretty unlikely that any improvement in software is going to spring from that kind of arrangement. Licensing is just more "Keep beating the engineers until things improve" with a taste of "Nice career you have here, be a shame if something happened to it, right?" thrown in. We already get that in industry, why invite the government, too?

light_hue_1 4y ago

The problem is that the current regulations around the PEng (Canada) and the PE (US) are nonsense when it comes to software. They don't lead to more accountability. They don't lead to better software. Getting a PEng or a PE is a liability, you're wasting your time as a student instead of learning something useful. To get a PEng or PE you have to take courses in, and pass an exam that covers, topics like power systems. This is a good idea for say a civil or mechanical engineer, since whatever they design will physically interface with all sorts of systems. They need that breadth otherwise accidents will happen. But software engineering is different. The problems with crappy software that lead to deaths, unfairness, etc. have nothing to do with software engineers not understanding power systems. Having people pass such exams contributes nothing to safety. Licensing organizations refuse to change. So they're simply not relevant to software. And as software grows, they're losing their grip on what is already the leading engineering discipline by far. There are more CS graduates (65k) every year than electrical (17k), chemical (8k), mechanical (20k), and civil engineers (15k) combined. Soon there will be more CS grads every year (65k) than all engineers combined (83k).

ghaff 4y ago
I don't believe the US even has a PE for software engineering any longer. I think something like 80 people got it after Texas initiated it.

kortilla 4y ago

> Right now when software kills people, they chock it up to a system or hardware failure. Where do you see this happening? 99.99% of software engineers don’t touch safety critical code. There is no reason to regulate them. It’s much better to regulate the safety critical products.

BeetleB 4y ago

> Right now when software kills people, they chock it up to a system or hardware failure. This is sensationalism. Systems involving safety usually have an associated ISO standard. If it's not being followed, there's more at fault than just the SW engineer. In many (all?) states, designing and building something that has safety implications requires a PE license by law - it doesn't matter if it's mostly a SW product or not. The individual engineers don't need the license, but someone in the chain does, and he/she is required to review the work, and it is his/her ass on the line if something goes wrong.