Software development seems to be one of the rare branches of engineering where people and businesses are ready to accept such low quality standards, both in terms of functionality and security.
We wouldn't accept from a civil engineer that "the bridge might collapse" but that it's "no big deal, takes a moment to rebuild".
It was one thing when software was controlling some random machinery in a basement or fueling our BBSes, but nowadays large-scale software failure can end a lot of lives, nothing less. And yet, society is largely oblivious to how fragile it all is...
Tbf, a lot of civil engineering is pretty basic physics with huge safety margins applied, and if the requisite test was "will it withstand a targeted attack at the most vulnerable point?" most structures would never have got off the ground.
I think most of society has experienced enough software crashes and had enough anti-virus warnings to realise computers are a wee bit unstable and insecure (as well as being well aware they can't judge secure software from insecure software). If anything, it's HN that's the outlier for faith in internet-connected software to do stuff like drive our cars safely.
Civil projects are certainly over engineered because the life safety risks are clearly understood by all parties making the decisions. Unfortunately the "most of society" argument is clearly not true yet. Otherwise they would be springing the cash for proper IT and software security.
When talking about bridges, roads, buildings, tunnels, power grids and sewage pipelines - just to name a few - there is one additional factor that we should always consider.
Once made available, all of these will see constant use and they become part of the fabric of society. Taking parts of core infrastructure out to fix then has severe repercussions. Total cost of invasive maintenance will be a lot higher than the fairly simply calculated cost of on-site fixes.
I will gladly accept overengineering and nearly ludicrous safety margins.
As someone who worked in Civil Engineering (EIT) who writes software now I'll agree.
When an engineer gets a license from the state they stamp the drawings. If anything goes wrong, they go write back to the engineer who stamped it. When I was in civil engineering we were asked to redo another firms calculations when things didn't go well (mostly slope stability).
Though for software, I did work on mission critical systems (radar), and they did have a pretty good review/testing regimen. They tested a lot.
For smaller shops, there is pressure to get it done fast and ship yesterday, quality isn't the first consideration. I think liability for attacks from your boxes that have been hacked is low, so even then people aren't as vigilant. See IOT devices..
A bridge is a largely static unmoving object, but even bridges require maintenance - some bridges require more maintenance frequent maintenance than others. It's not that bridges are necessarily of low quality.
If a the bridge maintainer instructed you that a column needed replacing it would be replaced.
Everything constructed in reality requires maintenance in one way or another. Your house, your car, your bridge and yourself for example. To suggest that software should be different is an interesting point of view.
> A bridge is a largely static unmoving object, but even bridges require maintenance - some bridges require more maintenance frequent maintenance than others. It's not that bridges are necessarily of low quality.
That's a laymans impression of what a bridge is. In reality bridges are in an extremely dynamic environment with loads changing magnitude and direction constantly, unpredictably. The fact that you think that a bridge is 'a largely static unmoving object' is a tribute to the engineers that designed it and the contractors that built it, it's whole function can be described as 'appear not to move'.
But if you looked at the bridge in a little bit more detail and you would see how the bridge copes with the load your estimate would change to 'a bridge is an extremely versatile structure that dynamically responds to a wide variety of loads by rejecting those loads onto the foundation and soil around it'.
Ok yes well. Mostly they can still be describe as largely static relatively, because thats the whole point of building them. Something stable to move across
Isn't one of the premises of modern engineering that you work within a regulatory framework to ensure safety for the public?
It seems to me that most software development is not engineering in this sense and I assume that we will get to that stage at some point, but right now things like public institutions being hacked, because their software security was not up to par, will happen.
We wouldn't accept from a civil engineer that "the bridge might collapse" but that it's "no big deal, takes a moment to rebuild".
It was one thing when software was controlling some random machinery in a basement or fueling our BBSes, but nowadays large-scale software failure can end a lot of lives, nothing less. And yet, society is largely oblivious to how fragile it all is...