But the way in which 'real world' engineering is treated by companies is extremely different to that of software engineering. A structural engineer tells you that your mega-bridge is going to take another 2 years to build safely and you eat up the cost, a software engineer tells you they need another 2 years to make sure your program will work reliably and you tell them they have 6 months.
It would be nice to see strict regulation on systems where lives would be endangered should the software fail, but this also raises the issue of how you regulate.
In Structural engineering you can say don't use material X if the forces acting on it exceed Y newtons. The same regulation in software doesn't make sense, you can't say "only use Haskell" or "don't use library Z" because the interactions between the tools we use are much more complicated than many "real world" engineering tasks.
We then run into the fact that a lot of software engineers have no real power in their companies, they do what management says or they get fired, I'd guess that when any other kind of engineer says "this won't work" managers listen. In my opinion a better solution to holding software engineers responsible would be holding the company and managers to account, at least at this point in time.
Correct, you can't declare language use as a requirement in the same way as material. Check out DO-178C, it doesn't do that. It requires artefacts and processes to be in place so that when the system is done, if done right, you have a high degree of confidence that written in C or Haskell or OCaml or Fortran that it was designed and tested well, and consequently that errors are minimized or by design their impact is mitigated.
And this brings us back to licensure, if we had a PE category for this sort of software engineering, where people really staked their livelihood on what they signed off on, these sorts of processes might be taken seriously. So when you're told, after giving a 2 year estimate, that you have 6 months, you can honestly reply: I cannot do that. And have a body to point to to back you up in your decision when you get fired and they hire on a less reputable "engineer".
It would be nice to see strict regulation on systems where lives would be endangered should the software fail, but this also raises the issue of how you regulate.
In Structural engineering you can say don't use material X if the forces acting on it exceed Y newtons. The same regulation in software doesn't make sense, you can't say "only use Haskell" or "don't use library Z" because the interactions between the tools we use are much more complicated than many "real world" engineering tasks.
We then run into the fact that a lot of software engineers have no real power in their companies, they do what management says or they get fired, I'd guess that when any other kind of engineer says "this won't work" managers listen. In my opinion a better solution to holding software engineers responsible would be holding the company and managers to account, at least at this point in time.