> If you're doing something that is a) very well understood and b) affects the safety of the public, then this is where engineering tends to be heavily regulated.

No, not really. Regulation is a risk management tool. You regulate activities with a recognized risk to society in general and stakeholders in particular. Consequently, you have fields where it is obligatory to have paid inspectors to verify safety and quality based on the existing standards and guidelines, and even the bulk of the design process consists in running safety verifications to prove a project is safe and reliable based on standardized procedures.

This type of care for safety and reliability is not observed in software development circles. Faults and failures in general do not have a critical impact on society as a whole. The subject of testing and verifications, unlike in real engineering fields, is somehow a hotly contested debate. The primary implication of a fault or failure is downtime, whose only concerned party is the service operator. The only resources wasted addressing faults and failures are man*hour from people already on payroll. This leads to what would represent, in real engineering fields, critical process failures that could cause a project to fail and even cost lives.

As it is software development, critical failures are acceptable and tolerated. A major crash at worst costs some engineer some time to sort out and recover. Seeing a rocket explode can bankrupt some companies and end peoples careers.

It's mind numbingly stupid to extend software development principles and practices to real engineering fields. The resources spent are not the same, nor are the implications of failure. Stakes are much higher, and naturally so is scrutiny and consequences.