>That is a flaw in business practice, it has nothing to do with software itself

I don't think it's a flaw and throwing this away isn't worth a quarter of the hassle that comes with any enforcment implementation I can conceive of. Please think about what testing, safety, security is "enough", how you test it, and if it's worth the tradeoffs.

Who is at fault for code violations? The scope of software is generally too big that prearchitected designs don't work and you must assign life safety faults to a PE. Software doesn't work like that, it's not singularly done. You shouldn't need to file a permit for expansion to add a feature or plug a security hole.

You point to solar, but solar is less complicated than the things most of this website would deride as simple in software. The electrical codes. It has hardly changed at all since it's inception, and only inspired a handful (<12) of changes since the 2008 NEC. Most jurisdictions only update every 2 cycles or so, so we're talking 3 updates.

Move fast and break things is fine when it's okay to break things; software is fundamentally different than physical infrastructure and you paint with really broad strokes here when you just assert "need" and "right".

I work with building code every day and I fundamentally disagree that writing a "critical software code" would be net beneficial.

> Software doesn't work like that, it's not singularly done.

This is definitely a business practice problem, and not some intrinsic quality of software.

And even if your business decides that software is never done, nothing stops you from getting a particular build inspected and certified. It's physically possible. The problems are in other areas: Governments are generally hesitant to regulate business. Software companies lobby extensively to keep it that way. Vendors and customers are generally not willing to pay the increased cost of software inspections. Developers don't like the idea of being held to a quality standard.