5 ms·

> 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 regulate

> 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.

birdiesanders 2y ago
Exceedingly close to zero people are at risk no matter how severe my mistake, because I build things that don’t carry risk.
rcxdude 2y ago
You are drawing the distinction along the wrong boundary: it's not software-vs-' real'-engineering, it's public-safety-critical vs not. There are in fact software engineers that work in the former, and most non-software engineering actually still works in the latter. And yes, a big, expensive expensive failure can be fatal to a company, but only if they've set themselves up to depend on it. (I've in general seen this strange sort of reverse-chauvinism from a good number of software engineers, who seem to believe that other engineering fields work in some much more regimented and consistent way to software. From someone who's worked in both, including seeing how the sausage is made on safety-critical automotive and medical devices, trust me, they're not much different: all that regulation barely pulls up the minimum bar a teeny tiny bit, at great expense)

birdiesanders 2y ago

Exceedingly close to zero people are at risk no matter how severe my mistake, because I build things that don’t carry risk.

rcxdude 2y ago

You are drawing the distinction along the wrong boundary: it's not software-vs-' real'-engineering, it's public-safety-critical vs not. There are in fact software engineers that work in the former, and most non-software engineering actually still works in the latter. And yes, a big, expensive expensive failure can be fatal to a company, but only if they've set themselves up to depend on it. (I've in general seen this strange sort of reverse-chauvinism from a good number of software engineers, who seem to believe that other engineering fields work in some much more regimented and consistent way to software. From someone who's worked in both, including seeing how the sausage is made on safety-critical automotive and medical devices, trust me, they're not much different: all that regulation barely pulls up the minimum bar a teeny tiny bit, at great expense)