You are under this illusion about other fields like architects because you don't work there and you can't tell. You don't know how the sausage is made.
Historically I have tended to learn about a new field WAY too much before I tried to hire people in these fields. The truth is, that makes it hard to hire people (but for good reason - depending on your needs, you need to pass on a lot of people). More recently I have tried to pay very close attention to how people do their work (about whose field I am building an interest). The sad reality of the world is that most people and businesses stay in business entirely through dumb luck and because the world is not usually THAT demanding. And if you have a specific requirement, they won't be able to help "out of the box".
You are imagining this competence. It doesn't exist in most people.
And to compound this, to me, the characteristic of an engineer is that they are capable of learning about a specialty discipline. If you hire an engineer and they are incapable of learning something that's needed in your project, THAT is where their problem is (and yours for not hiring to that.) Engineering is not a trade. Certifications are usually about selling them or gatekeeping. I wish it were possible to certify "engineering progress mindset" - no, it doesn't have an ISO number.
On the contrary, I am fully aware that there exists no field where a test or piece of paper guarantees excellence.
But I am also aware what the lack of it does. It leads to buildings falling down or burning up [with people in them]. This was a common occurrence 100+ years ago. You know what made it less common? Standardization. Building codes. Minimum standards for engineers and the trades. Independent studies have all concluded that real world outcomes improved across the board because of these things.
No formal certification or standard will lead to perfection. That is obvious. But what is also obvious, from actually looking at outcomes before and after their introduction, is that having them leads to better outcomes.
You have to stop thinking about individual engineers, and start thinking about the much, much larger picture. What changes will have a positive effect on the larger picture? You can only have an effect on the larger picture if you enforce a change across the board, and then look at the aggregate results.
That can not happen without a mechanism to enforce the change. We can't pray our way to better results, or just sit around hoping people magically get better at their jobs, because that clearly has not happened for the last few decades that I've been working.
The more we depend on technology, the more we see the failures of a lack of rigor. Probably every single person with an address and social security number in the United States has had their personal information leaked, multiple times over, by now. Lives are ruined by systems that do not take into consideration the consequences of a lack of safety, or the bias of its creators. Entire global transportation systems are shut down because nobody added basic tests or fail-safes to critical software infrastructure.
This shit isn't rocket science, man. It was all preventable. And just like with building codes, standards, licenses, etc, we can put things in place to actually teach people the right way to do things, and actually check for the preventable things, by law. If we don't, it's going to keep happening, and keep happening, and keep happening, and keep happening, forever.
We can do something to stop it. But we have to pound our fist on the desk and say, enough is enough. We have to put something imperfect in place to stem the tide of enshittification. Because there are consequences if we don't.
We have seen some of them globally in the form of warfare, but nothing compared to the devastation when the gloves come off. We have not yet seen an entire country's hacker resources attack the water, power, sanitation, food, and other systems of its enemy, all at once. But it's going to happen. And it's going to be devastating. Millions of people are going to die because some asshole set a default password on some SCADA systems. But it should have been impossible, because no SCADA system should be allowed to be sold with default passwords. That's the kind of thing we can prevent, just like you can't build a building today without a fire exit.
That's the really big obvious impact. The impact nobody sees are from tiny decisions all the time, that slowly affect a few people at a time, but on the scale of millions of businesses and billions of people, add up to really big effects. We can make a huge difference here too, which will only be visible in aggregate later on. Like public sanitation, clean water, or hand-washing with soap, nobody thinks about the dramatic effect on public health and longevity until it's clear after decades what kind of impact it made. Technology is everywhere, in every home, affecting every life. The more we improve it [as a standard], the more we will see huge positive impacts later.
> It leads to buildings falling down or burning up [with people in them]. This was a common occurrence 100+ years ago. You know what made it less common? Standardization. Building codes. Minimum standards for engineers and the trades.
To me, this is a more interesting comparison. Is it PE certification and contractor licenses that led to this or is it building codes, construction inspectors, occupancy permits? I will argue that it's inspectors, NOT PE or contractors. And I will argue that the buildings codes have major negative consequences also. We all know of constructions methods that would have great benefits but have to be abandonned because they don't easily fit the current code. We all know of buildings that are to-code and yet ridiculously noisy and cheaply built.
I will also argue that there are building code equivalents already in software and system architecture. There are several for "certifying" system or site security and systems that host credit card payments. And we all know how well they work. So I agree with you that there is room for progress there, but I will also argue that the approach NEEDS to be different. The current security or payment checklists are bureaucratic, CYA nonsense which discourage thinking and encourage bureaucracy and CYA specifically in place of actual security. The only thinking they encourage is creative writing to twist reality into the proper buzzwords.
There may be a way to specify practices and security but we sure have not discovered it yet. So, a research question rather than already a standardization question? I will point out also that there WERE directions that did work in the past. For example, Dan Farmer and Wietse Venema's SATAN (and the several descendants since then) was bureaucracy-free: the test showed specific rubber-meets-the-road issues with your system that you could either fix or defend. No bullshit about using a firewall(tm) "because that's best practice".
I also don't say that it's bad to publish books. I will say that it is bad to push "best practice". "Best practice" is precisely bureaucracy and CYA in place of thinking. To the point of site owners defending their lapses in the name of "best practices".
What else currently goes in the right direction? Pen testing. Bug rewards. Code reviews.
You really need both. Mandatory education, degrees, apprenticeships, licenses, etc is how you make sure they know how to do the thing. And then the building codes and inspections is how you check that they did the thing. If you ask someone to build a home "to code" but you never teach them how, they will spend years trying to figure it out, inconsistently. Send them to school, have them apprentice, and afterward they will be able to build it in a month, in a standard way.
You remind me, there is an industry that has some basic software building codes: the Defense Industry. There are some pretty thorough standards for IT components, processes, etc needed to work with the military (even in the cloud). But it is all self-attested, so it's like asking a building contractor to make sure they inspect themselves. Government keeps asking the tech industry to solve this, but nobody wants to take responsibility. As more and more stuff falls apart (in the public & private sector) the government is gonna get louder and louder about this. It's already started with privacy & competition, but big failures like Crowdstrike make it obvious that the rot goes deeper.
I agree that the US defense sector is an excellent example of the kind of credentialism in software that you, and the IEEE, are advocating! And the results are dismaying. As Anduril says in https://www.rebootingthearsenal.com/:
> Despite spending more money than ever on defense, our military technology stays the same. There is more AI in a Tesla than in any U.S. military vehicle; better computer vision in your Snapchat app than in any system the Department of Defense owns; and, until 2019, the United States' nuclear arsenal operated off floppy disks. (...) today, in almost every wargame the United States Department of Defense models against China, China wins.
Of course the DoD's problems go much deeper than just credentialism, but credentialism is definitely one of the causes of the disease, not a palliative measure.
> Is it PE certification and contractor licenses that led to this or is it building codes, construction inspectors, occupancy permits? I will argue that it's inspectors, NOT PE or contractors.
You seem to think that with enough process and forethought you can avoid almost any disaster. My experiences have shown this to be false and I've seen this type of thinking actually make things more opaque and harder to work with.
The failures you're talking about with SCADA and security breeches will not be solved by some licensing where you check a box saying "thou shall not use default passwords", they'll be solved by holding companies responsible for these failures and having good safety/security requirements. A class isn't going to fix any of that. It's a ridiculous notion.
Historically I have tended to learn about a new field WAY too much before I tried to hire people in these fields. The truth is, that makes it hard to hire people (but for good reason - depending on your needs, you need to pass on a lot of people). More recently I have tried to pay very close attention to how people do their work (about whose field I am building an interest). The sad reality of the world is that most people and businesses stay in business entirely through dumb luck and because the world is not usually THAT demanding. And if you have a specific requirement, they won't be able to help "out of the box".
You are imagining this competence. It doesn't exist in most people.
And to compound this, to me, the characteristic of an engineer is that they are capable of learning about a specialty discipline. If you hire an engineer and they are incapable of learning something that's needed in your project, THAT is where their problem is (and yours for not hiring to that.) Engineering is not a trade. Certifications are usually about selling them or gatekeeping. I wish it were possible to certify "engineering progress mindset" - no, it doesn't have an ISO number.