Man, the people who push certification systems on the software engineering community really burn my biscuits.
I haven't seen a certification system that wasn't either a money-grab (product-specific certifications, like Windows or Novell), a power-grab (by someone like the IEEE, where the tests were half electrical engineering and the software bits were garbage practices from the 70s and 80s), or a way to artificially restrict the number of available practitioners (arguably another money-grab).
No certification system is going to magically make large systems easier to write or whisk away bugs. Writing software is hard. It's that simple. People who have spent their entire careers writing software, from industry luminaries that you read about every day to the really, really good engineers you've never heard of, who are absolute wizards, these people are still writing howlingly bad bugs because writing software is hard.
You can have your certifications and legal requirements for training and so on, just don't pretend they will improve the state of the art. The best you can do is hold people's feet to the fire after they make mistakes, and if the best people in the industry can't be perfect, why would we expect threats of punishment to fix anything?
Engineering is about designing and building systems, usually with cost, time and reliability constraints. It's totally separate from whatever liability framework is being enforced this week.
It's not about being perfect, it's about being fault tolerant, just like regular engineering. I think especially for safety-critical situations (cough Boeing cough) there needs to be stringent, formal standards for quality, review, and training. It should not be possible to cheap out or ship a pile of duct-taped garbage in some situations, and that requires external review by subject matter experts. (Not necessarily government bodies, especially with the regulatory capture and brain drain going on right now.)
I think kabdib's point is that the incentives of certification authorities aren't aligned with the purported goal of the certification process. We already have all sorts of certifications (in specific technologies, "agile" practices, etc.) but I don't think most engineers see those certifications as providing any value.
The only thing I'm aware of that seems to actually work is to hold engineers accountable for results and give them the autonomy to set their own process. I would argue that even very rigorous methodologies like NASA's Systems Engineering[0] process match that description.
I am a "Software Engineer". I hold a Professional Engineer designation by APEGS, my schooling was for Software Engineering. I advocate for regulation in the industry but also don't think it needs to be sweeping and catch-all.
My job has me working within Industrial Control environments. Programming mistakes can kill people or damage equipment worth millions. When I receive a software package from someone I want to have some trust in a system that this person wasn't hired off the street for lowest wage. My employer has a good reputation in our industry and is asked to come clean up messes from programmers overseas who provide a bad system and walk away from it.
If your job doesn't have you playing with lives of people or holding the wellbeing of a company in your hands then regulation shouldn't be as stringent. But to say that every project of that magnitude has an Engineer overseeing and holding responsibility over it isn't overreaching imo.
I think they were advocating something along the lines of a Public Engineer certification, not the trivially useless certifications we have today. One of the things making programming difficult are inexperienced people kibitzing with management and telling them the reason things are taking so long is the experienced people are gold-plating everything. Professional certifications would go a long way toward solving that problem.
OTOH, not every engineering project requires a PE - and the same would be true for programming as well. Unless money, lives or other regulatory items were on the line then a PE would not be required. That would still leave the overwhelming majority of software not requiring any form of certification for its creators. So there's that.
I haven't seen a certification system that wasn't either a money-grab (product-specific certifications, like Windows or Novell), a power-grab (by someone like the IEEE, where the tests were half electrical engineering and the software bits were garbage practices from the 70s and 80s), or a way to artificially restrict the number of available practitioners (arguably another money-grab).
No certification system is going to magically make large systems easier to write or whisk away bugs. Writing software is hard. It's that simple. People who have spent their entire careers writing software, from industry luminaries that you read about every day to the really, really good engineers you've never heard of, who are absolute wizards, these people are still writing howlingly bad bugs because writing software is hard.
You can have your certifications and legal requirements for training and so on, just don't pretend they will improve the state of the art. The best you can do is hold people's feet to the fire after they make mistakes, and if the best people in the industry can't be perfect, why would we expect threats of punishment to fix anything?
Engineering is about designing and building systems, usually with cost, time and reliability constraints. It's totally separate from whatever liability framework is being enforced this week.