Consider existing professional certifications, like, for example, Cisco certification. How many top tier people have it? Some do, but in my experience, not many. Instead, they are overwhelmingly held by low-to-mid skill people, who see it as a ticket to a better job. Top tier people can easily get top tier job, and have no need to waste time on some certifications.
But in software? If management says you need to cut corners to get something out by an arbitrary deadline, well, you cut the corners or they'll find someone who will.
At the end of the day, you still work for them, so with enough "nos" they'll just fire you or assign you to projects which don't matter.
As an electrician for example, we have to check almost everyrthing with various tests and sign it with my name.
For me, the software world still looks and feel like wild west.
They'd have to replace you with someone else similarly certified.
Software certifications, afaik, are not like this, but instead are sort of like merit badges.
In any case, if PE was required to work in software, I wouldn't have had a job in the first place, so I'll always oppose these kind of efforts to shut out the outsiders and underprivileged people.
In any case, I can ASSURE you that it was comprehensive, and you have to "know your stuff" to pass it. I've been Microsoft certified, so I've seen this side too. If there were a similarly-reputable license in software engineering, there would NOT be "certification factories" to crank out people who can pass the cert test, and who can do little else. I don't know what the analogue for doing actual mechanical/electrical/civil engineering problems would be in the software engineering realm, but that's the KIND of thing that would have to be tested. It would require a working computer and internet access, and not a duffle bag of engineering textbooks, like I had. ;-)
If almost no one wants them, then they would pay very well and be in high demand, and that comes with lots of benefits and perks, and you can require the use of the best tools to ensure those disastrous outcomes don't happen. So yes, I'd take that job.
I work in "automotive," and my company created an internal textbook on waterfall development 25 years ago. I know, because I was part of an external consultancy to review it. And it was great! At waterfall! And they're still using it! Now we're getting into alternate power, and we've lifted the same software process we've been using since we had to break our firmware into 8 pieces BECAUSE THAT'S WHAT FIT ON A FLOPPY to send to the plant to upload into the ECM, and started using it with completely new build systems and processes. We've hobbled what could be a completely fresh start with 25-40 years of technical debt before even getting started. I would posit that heading off this train wreck was the place of the CIO or CTO, but they just made the CIO the CEO, so ¯\_(ツ)_/¯.
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.
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.
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.
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.
Proper engineers learn them, not random dudes that decide to call themselves "engineers" after a six weeks bootcamp.
In civil engineering and other, individual engineers can face consequences for disasters like collapses.
And other disciplines; a surgeon can face consequences for a surgery that was done by a team, and so on.
The first person to get jail time during the 'DieselGate' scandal was James Liang, surprise surprise an Enginnering Head at VW. An army of Execs and C-levels were in the know but the first guy to go is a low-rank Engineer.
My point is execs and C-levels always claim that their pay is justified by the risk and liability of their decisions but when the wheels hit the tarmac things change very quickly.
Improve regulation, fund regulators, incentivize companies to fund quality processes.
People without actual engineering background (should) have no place in safety critical systems design.
I don't think it needs the credentials, it just needs (language?) to distinguish between roles where you can sign off on a product and be held legally liable if the product is found to fail its specification.
This, in my mind, is the difference between a software engineer and a software developer (I consider myself a software developer).
I’m not sure what the solution to bad software is, but I don’t think it’s making the spec higher stakes.
https://ncees.org/ncees-discontinuing-pe-software-engineerin...
Here's a scenario. You're nominated to be an ECU supplier or a software sub-supplier for a VW brand, first thing they hit you with is requirements which span 1000 pages for a simple system (door, seat, HVAC), or 10x more for a more complex one (infotainment, engine ECU, "main" vehicle ECU etc.). 1 of those requirements is "SW shall comply with VW 8xxxxx norm" which is one of many VW norms that they deliver to you. The other requirement is "SW shall comply with KGAS", KGAS stands for "Konzerngrundanforderungen Software" which translates to "Group Basic Software Requirements", (group is VW), and both, you guessed it, are thousands upon thousands of requirements.
Then there's Functional Safety, or FUSA, which is a reference to ISO26262 (based on IEC 61508). Then there's also ASPICE (ISO/IEC 15504). New thing is UNECE R155 (cybersecurity). These three prescribe a very detailed development process commonly known as the "V model" for system and software development, which means you need to elicit requirements, define system requirements, system architecture, software requirements, software architecture and software detailed design. After that, you get to coding. For each of those there's a validation method: unit tests, software integration, software qualification, system integration and system qualification. ASPICE 4.0 has expanded to cover Embedded Hardware and Mechanical design as well. Other than the engineering processes they also cover other areas such as project management, configuration management, supplier monitoring, problem & change management etc.
Then come the external and internal audits, pardon, assessments. Your internal Quality department needs to monitor all engineering activities and report them to the customer, customer's Quality dept. will do their own audits, you and them will also hire an independent company to audit/assess you so that there's no bias.
BUT guess what - almost none of this is required for non mission critical software, so your infotainment is actually the only thing developed in a way you've described it. Brakes, ABS, ESP, Engine ECU or the EV powertrain (BMS, inverter etc.) are all written according to what I described above. There's no need for more bureaucracy, the automotive industry (especially German one) is very good at self-regulating and would make an average web developer throw up on his first day. Failures of the UX/UI in modern vehicles is just a business problem - guys who spent decades building and selling options like leather seats, and checking spreadsheets at the end of a fiscal period are still at the helm or their business processes still live on in those companies.
And who will handle the distribution of that credential... The moment it is required to have one, thousands of private universities of questionable quality will be dispensing such credentials just like how they have been dispensing engineering titles. Totally legal. What difference will it make compared to the existing situation...
Or is it so that these credentials should be distributed by a few elite institutions to make it safer.
What difference does this make from the current situation in which top corporations hire top people for top tier work? So everyone will have to hire MIT, Pekin U, Tokyo U or Berlin U graduates?
And what happens when centers like San Francisco suck all of those graduates away from the rest of the market and cram them into the expansive tech business? Leaving the Automotive industry as scarce of such top talent as it is now? Will the auto companies pay more money than Google et al to attract that top talent? Something which they could easily do now, but arent?
...
So basically your proposition will not change anything, but it will just introduce more bureaucracy into software.
And state, that is behind in everything related to technology, is going to be the arbiter of the 'best practices' in a field that progresses faster than what even the top universities of the world can cope up with...
So basically this would force software into a profession lagging from ~100 years behind like other engineering fields...
I think the main problem is that there is no competition since you are buying the car not for the software (at least most people don't).
Make car software an open marketplace, and you will see improvements in quality.
For infotainment inside the cockpit sure knock yourself out. But I absolutely do not want to be on the road or at crossing as a pedestrian with cars running modded ABS or ESP units.
I don't think any car manufacturer combines the functionalities you mention in a single software system so it would be easy to separate them.
Over the years, I've seen various discussions brush up against the issue of professional certification. Professional Engineer, in civil engineering, is a serious credential, which can hold people professionally liable for bridges that fail, or buildings that fall over. Making cars a network of computers that all talk to each other, operated entirely "by wire," and giving up any consideration of mechanical backups (like with a plane) is going to very quickly drive the point home that the programming profession needs a similar credential. As a mechanical engineer who has made a living writing software for 30 years, I understand the difference, but the legal externalities are not going to care that software is VASTLY more complicated than, say, designing a plane wing with a factor of safety.
Now, I have to go figure out why my Rails application can no longer restart the delayed_job process on deploy. Is the problem in Rails, Ruby, my gems, Capistrano, permissions, SSH, or some updated package on my Linux VM? Designing a bridge, frankly, is easier, because it's "concrete" and closed-form. Sure, I'll figure out my deployment problem, but next month some obscure thing in the 24 layers that make up a simple web app these days is going to get updated, and break something else. At least once a bridge is built, it's done.