I agree with you but I would extend that observation to include the age of the industries. We have been making structures for thousands of years. Software is an infant compared to that.

I think that has more to do with than some unverifiable sentiment like "software people are simply inherently less serious than other engineers".

[delayed]

You do. Structures fail. Less so in parts of the world where serious regulations are in place.

Structural engineering, is engineering (though mechanical engineers would disagree), 'software engineering' not so much. It just happens to be a word that's a useful synonym for 'building things'.

I rarely call myself an 'engineer', preferring developer or programmer.

Isn't software "engineering" or shouldn't it be considered that? Creating a new painting program might not be considered that and a software failure would have little impact, but there is a huge amount of software which is essential for the operation of complex systems. We just had large parts of the internet impacted by the PHP bug - a lot of businesses were harmed in their fundamental processes by it. Like if a roof of a warehouse had collapsed.

In Europe, a lot of supermarkets were hit by a remote exploit which allowed attackers to switch off cooling of food. A blood bank in France was attacked the same way.

So how would building software for important or even safety-relvant systems not be considered "engineering"?

Especially, as faulty software might not only cause a product or device to fail in a dangerous manner, faulty software in this day and age often makes it possibly to remotely attack the faulty product.

I think 'engineering' is a useful synonym but I just don't think it's appropriate for our industry, and is a disservice to actual engineers.

Sometimes software is a public works project but sometimes it is a backyard shed. You just have to know the difference.

And I could get a structural engineer to check the integrity of a shed in very little time indeed. Sounds fine to me

But would you? Why or why not?

We don’t have time to tinker about for months on regulatory processes and making the our screws are “B6”. Software is a different industry.

The state space of what you must check to ensure correctness in physical engineering is infinitesimal compared to ensuring correctness in software. Correctness in software is qualitatively more difficult by nature and an open problem at a theoretical level.

No amount of bureaucracy and process theater gets around this fact. There is a vast and very expensive gap in software between "don't do stupid things" and "this is actually correct". The tooling to close this gap is severely deficient and not for lack of trying. In physical engineering we've had automated design checking for decades because it is a relatively trivial problem in those domains.

It would be great if compilers could generate proofs but after decades of research they can't even generate SIMD code in most contexts.