The idea that the best solution to computer complexity is more bureaucracy and a professional cartel is absurd.
We know how to solve the problem of software reliability. We have a rich body of formal methods that allow us to build perfectly reliable computer systems, up to the failure envelope of the hardware itself (from thermal, radiative, mechanical, etc. stress).
The reason we only use these techniques on certain critical systems is that the cost is somewhat higher than normal "unsafe" development and the incentives are not there yet.
Instead of turning our industry into a horrific morass of red tape, with questionable upside and unquestionable downside, let's just incentivize the use of correctness technology where appropriate.
The use of formal methods in safety critical code is already well-established. MBD is a very common method to write ECU software, for example. It's not universal though and proofs of the more complicated system requirements are challenging at best.
Well, to be fair, I'm not saying that certifying software developers is reasonable. As a practical matter, the industry moves too fast anyway. A PE license is for life. Even if there were a software engineering license, I wouldn't necessarily trust someone who was licensed back in the COBOL days to know anything about modern web development. I'm just saying that if there's enough LEGAL pressure, this is almost inevitable. A Fortune 1000 company is not going to just absorb the costs of failed products (like self-driving cars killing people), and do nothing about it to cover their asses.
> A Fortune 1000 company is not going to just absorb the costs of failed products (like self-driving cars killing people)
Except, that's precisely what they do. Such costs are calculated into the product when it is being developed. Just read about the Avandia drug scandal.
>"A Fortune 1000 company is not going to just absorb the costs of failed products (like self-driving cars killing people), and do nothing about it to cover their asses."
And introducing certification is not going to to stop the killing and will not "cover their asses" either. Out tech currently is simply not adequate to solving this problem in the way acceptable to corporations and the end customers.
This is why I do not understand people being called software engineers when they're anything but. As you said engineer is more about ethics and liability. I am designing and developing software for more than 40 years but I would never call myself an engineer. Nor would I ever want to become one.
When it comes to the issues of safety the proper outcome should be organized by a processes, verification and other things that would not let that piece of code get into production. Putting this kind of load on software developer I think is utterly demented idea.
For engineers the foremost value is safeguarding human life and the second might be protecting the environment. If anyone is developing software that can cause loss of life or damage the environment then I think the engineering ethics and processes you mentioned are a necessary load. Of course then the output of the
Programmer is reduced, but that is the tradeoff to make for the type of code flying airplanes or driving cars
The processes and other things do not have to be set by programmer. It is insane to have programmers do all those things. Their task is to design develop software given constraints. Safety is a constraint that can be specced separately. And testing should be done by the independent team
Exactly why any good Software Engineering, certified from Engineering Society of the respective country, has formal methods as part of the compulsory lectures.
Proper engineers learn them, not random dudes that decide to call themselves "engineers" after a six weeks bootcamp.
We know how to solve the problem of software reliability. We have a rich body of formal methods that allow us to build perfectly reliable computer systems, up to the failure envelope of the hardware itself (from thermal, radiative, mechanical, etc. stress).
The reason we only use these techniques on certain critical systems is that the cost is somewhat higher than normal "unsafe" development and the incentives are not there yet.
Instead of turning our industry into a horrific morass of red tape, with questionable upside and unquestionable downside, let's just incentivize the use of correctness technology where appropriate.