(In interesting ways this is programming’s greatest boon and curse: if we treated it more like building bridges or cars, the world would be a very different place.)
I had to make some software changes to an old medical device this year. The overwhelming majority of the effort was understanding what the customer wanted and giving them feedback into how that would change the existing system and the risks associated. Then, creating a plan to follow the necessary standard (IEC62304) and creating the associated documentation and getting it reviewed and approved.
The actual code that changed was probably only around 100 LOC but the project took several months. Heck, the code was simple enough that an intern could have done it.
(The distinction I’m making is between the code that operates the medical device and the code that operates the app I make doctors’ appointments in. The latter is subjected to a different - and lighter - regime than the former.)
Because when I submit building plans, they are manually reviewed and approved (or denied) by registered architects, engineers, and planners employed by the authority for just this purpose.
I'm sure other highly regulated industries also have their code audited.
There are the executives, the lawyers, the product managers, sometimes the designers, who to varying degrees determine this before they land in the requirements the programmer sees. But there are also the libraries and APIs the company pays to handle compliance so that the company and the programmer doesn't. The programmer implements the library (and may not even had a say in or necessarily care which one was chosen).
The level of quality needed (or imposed) will vary. It is a wide spectrum from dealing with banking/transactions (money at risk) to brake controllers and auto pilots (human lives at risk). But there is a lot of this, all over the world.
I work somewhere in the middle (rather slow but extremely heavy industrial equipment, where emergency stop is always a safe if costly option). There are domains where emergency stop is not a thing though: some systems on an aircraft in flight, a pacemaker, etc.
My point is though, that there is a ton of code where stakes are higher than "oops, I guess we will fix it next sprint". And while not all of that have regulatory constraints, sometimes a company realises that the financial cost of issues significant enough that it is worth holding themselves to higher standards anyway.
I mean, this was drilled into me at uni — that software was not likely to escape regulation forever and that you can't know with certainty how all the code you're writing will be used when you're not observing the use.
For example, under what constraint regime should the calculator app bundled with an OS be written? It's just a little bundled toy app. Until someone under pressure uses it to calculate a medicine dose, expecting it to be a calculator like it says.
Perhaps this gives away my age more than anything else.
This captures a sentiment I have often felt when people don't take bugs seriously. Or don't take it seriously that they introduced regressions. You should feel personal responsibility for your bugs. When your shit doesn't work, and people are trying to use it, you are basically hurting them, personally.
But it seems with the increase of AI coding, the industry is going the other direction. Nobody seems to care about bugs introduced by slop coding. Except perhaps the users.
I honestly have failed to see the value of anyone wearing an official "Software Architect" hat in my 20 years of being in or leading high performing software development teams: yes, we built and maintained complex systems with multi-team dependencies, did that effectively and maintained and evolved them over time.
I've seen an Architect who is still doing the coding, but they are never available when you need them. I've seen an Architect who is always available, but so far removed from actual project that their advice is only somewhat worse (if they are good — or a lot worse if they are bad) than what a good senior in the team engineer or tech lead would offer. And an Architect who would happily design for the use cases that might come in 2 years (read never) using complex abstractions only they can understand, leading to decoupling of architectural pieces to 10 teams which could be built better by 1 or 2.
Do I want our industry to be regulated by these folk? No.
I have nevertheless always written code on the basis that it might one day encounter proper scrutiny.
Ultimately in the parallel universe where chartered software engineers became the norm, the scenarios you are talking about would be different, for structural reasons.
It's never going to happen in this universe.
However, I am currently in an enterprise org suffering from compliance/certification overhead while pretending that they do all of the good stuff topped with a highly infectious NIH syndrome (we build our own payment system, authentication system, wrap all the levels of cloud platforms and mobile platforms...). Trying to put more quality in gets opposition from... Quality Engineering, which is a separate department of people who've never written a line of code in their lives — because they need to be consulted and give a stamp of approval on any change, even if it's for the better :O We've got highly specialized roles of Software Architects, System Architects, System Engineers, Quality Engineering, System Validation, Software Validation, System Verification, Software Verification... It frequently becomes funny trying to make a single decision ;-) I don't have to imagine a world where something like this happens, because it exists in some enterprise orgs.
But the fact of life is that even in actual civil engineering, at every phase of building, there is a step of reviewing construction as it is built when constructions actually diverges from the project (happens quite a bit). Most of these get approved if they are not detrimental to the core function and structural integrity — this leaves the opportunity to contractors to actually do what makes more sense from their experience and still pass inspection.
This group of people would never understand that because they are mostly optimizing for appearing useful and invaluable, instead of for business or customer value.
Yeah — perhaps unsurprisingly an industry struggling to cope with absurd complexity and change has invented and in some cases reinvented a lot of the kind of tooling and process that engineers were talking about in the 90s.