Is software engineering a real engineering discipline, though? I have a hard time saying yes when "software engineers" make mistakes that are well documented, no certification is necessary, and it isn't a legal definition.
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.
In my state, you need a license to offer engineering services to the public, but not if you work for an industrial employer. However, your design may have to go through a regulatory approval process, and the people who are hired for that work are licensed engineers. In some fields such as civil and nuclear engineering, so much of the work is regulatory, that they only hire licensed engineers as a matter of course.
In my view, "engineer" is getting harder to define. At my workplace, anybody who does anything techy and has a degree is an "engineer" if in the product development department, or a "scientist" if in R&D. Only a small handful of the engineers do what a traditionalist would recognize as "hard" quantitative engineering. Most of the work is fitting building blocks together, troubleshooting, bureaucracy, etc.
There are people who know how to construct reliable software, Joe Armstrong having been one. I don't think this knowledge has crystalised into a profession yet.
Yes, because you can be a chartered engineer off the back of software development experience and a CS Masters. There isn't a more definitive way to say yes or no than that imo.
But will that really help though? It'll just be another mechanism for signaling, but that doesn't mean it will improve the situation, because the technology moves so fast that it's virtually impossible for the certification to be relevant, unless you mandate that software engineers get a certificate every year in some arbitrary newest technologies.
Engineering is a field where we understand the fundamentals. Changes from year to year or even decade to decade aren't going to uproot half of the things you know about it. In software that can very much be the case.
Goodhart's Law applies, so you can't have a set-and-forget certification process. It can be a dynamic process. And just perhaps, we should disincentivize trying to launch new technologies when the institutional knowledge is not there yet. I wonder how many of those security compromises come from bad tradeoffs trying to "keep up with the Joneses" instead of addressing technical debt and knowledge gaps?
The problem is that this is an industry of tinkerers. A lot of projects started out and continue to be maintained by people that do it as a side project. How are you going to police that? People seem to build software as a hobby and sometimes that morphs into a library.
If a tinkering structural engineer designed some new type of, say, a joist, would builders just throw it into a new structure because it's new, or would it need a vetting and review process before becoming a structural dependency? Review doesn't need to happen at the creative level, just at the level where new code gets integrated in some non-trivial, safety-critical deployment. That happens informally now, as people submit issues, pull requests, etc. for projects that they're interested in, but sometimes that is not enough and calls for something more rigorous, like the peer review process in science. Things like the npm left-pad incident clearly show that we're favoring expediency and speed far too much over resiliency. Software now in many places is where architecture was before building codes and fire escapes.
