Hacker News Reader

Comment by zanellato19 | Hacker News Reader

Given the same conditions (i.e. people don't die) the same outcome would present itself. We have a history of bridges falling down, so much so that Wikipedia has a list on that: https://en.wikipedia.org/wiki/List_of_bridge_failures

A particular one that caught my eye: Cimarron River Rail Crossing Dover, Oklahoma Territory United States 18 September 1906 Wooden railroad trestle Washed out under pressure from debris during high water 4-100+ killed Entire span lost; rebuilt Bridge was to be temporary, but replacement was delayed for financial reasons.[8][9][10] Number of deaths is uncertain; estimates range from 4 to over 100.[11]

Emphasis mine. How is that different from software engineering?

View on HN

The point isn't that bridges never fall down. The point is that engineers who build bridges know that it's their responsibility to do everything in their power to make sure it doesn't, even if no-one else around them seems to care about that, or specifically asked for it. That they should walk away from a project rather than sign off on one where they will not have the resources or support to do a competent job.

That said, all bridges have design specifications and limits. If someone drives a convoy of trucks carrying gold bullion over a bridge and exceeds its design max weight by a factor of 10, and it doesn't hold up, that's not the engineer's fault. If a bridge is designed for a geologically active area and is designed to withstand a quake 10x more powerful than the strongest that's ever been recorded in the area, or is predicted by seismologists, and the area gets hit by a 100x quake, that's not the engineer's fault.

And if a bridge designed to last say, 5 years, is neither re-certified for use, or just closed, when its intended lifespan is up then that's not the engineer's fault either.

But the engineer is responsible for finding out what the likely max load of a bridge will be, or how powerful the strongest quake will be, or how long its intended lifespan is - and for adding in safety margins on top of that. They can't just assume that any new bridge will only be needed for 5 years, just because that no-one told them that it will be needed for longer, and then claim "well, it was only temporary" afterwards.

> The point isn't that bridges never fall down. The point is that engineers who build bridges know that it's their responsibility to do everything in their power to make sure it doesn't, even if no-one else around them seems to care about that, or specifically asked for it. That they should walk away from a project rather than sign off on one where they will not have the resources or support to do a competent job.

The law takes care of that though. The law and inspection. If it was up to the business, any engineers building bridges who would refuse to project it faster because of that would be fired.

A thief thinks every man steals. An apathetic engineer thinks all engineers share his apathy.

The sarcastic/negative implication of your example is that software engineering today is where civil engineering was 100+ years ago.

I don’t think that is too far off the mark. Given 8 more decades of progress we might even be able to produce reliable code. Webpages will be 100GB of JavaScript though

I think reliability is, after a certain point, inverse proportional to the amount of code involved. So I'd disagree that we'll have even larger webpages then - the same way that in modern construction, heavy and thick stone & brick pillars have been replaced with comparatively light and strong steel-reinforced concrete. Maybe the equivalent would be just enough strongly typed code running on top of just enough, well tested & secure WASM?

> Given 8 more decades of progress we might even be able to produce reliable code

As the risk of nitpicking, we already can produce reliable code, but as piaste's comment states, it's rare to make the necessary investment.

Avionics software and medical systems software is held to a very high standard, at great expense, but the average website or desktop application is not.

> Webpages will be 100GB of JavaScript though

I agree that the problem of bloat is likely to continue to worsen in the web, but that's just the web. Other sectors, like high-performance game engines, will continue to compete on efficiency.

made me chuckle.

Yes, but not because software engineers are worse human beings than civil engineers, which is all too often the undertone of these discussions.

Rather, because software engineering hasn't killed enough people to advance; or when it has, it wasn't obviously the culprit.

In which fields of software engineering do we find actual solid procedures and standards? Avionics. Medical hardware. Fields where the link between bug and death is as short as possible, and so the stakeholders have demanded solid engineering.

What are the consequences of GP's acquaintance writing poor code? Some trading firm becomes slightly less efficient at trading. Impossible to evaluate the net human loss from it (if it's a loss at all).

The civil engineering equivalent would be something like façade design or layout. If your building is ugly or confusing, it will annoy or waste the time of the people who live and work in it, but as long as it doesn't fall on their heads nobody is going to withdraw your certification.

> not because software engineers are worse human beings than civil engineers, which is all too often the undertone of these discussions

I think the undertone is usually that the software developer at fault had no idea what they were doing, and had no place working on critical systems, rather than that they had ill intent.

> software engineering hasn't killed enough people to advance

and where it had, you get pretty serious control and certification process put in place to avoid it (Boeing notwithstanding)

The 737 Max issues were not with the software.

There seems to be plenty of software issues found:

The MCAS software was modified to read from both angle of attack sensors and to be less aggressive in pushing the nose of the plane down. The software that controlled the indicator light that illuminated when the two angle of attack sensors disagreed was also fixed.

While reviewing the software systems, a number of other software issues were found.

The wiring bundle issue was also found during these reviews.

https://www.barrons.com/articles/these-6-issues-are-preventi...

https://simpleflying.com/boeing-737-max-software-update-3/

I phrased that poorly, I should have said The 737 Max issues that caused the crashes were not with the software implementation. They were at the level of requirements and high-level design, and were not specific to the discipline of software engineering. We're not talking about a missing break statement here.

> The MCAS software was modified to read from both angle of attack sensors and to be less aggressive in pushing the nose of the plane down.

That strikes me as a design issue in the domain of aeronautical engineering, rather than in software engineering. Software engineers aren't the ones with the domain expertise to determine the right aggression parameters.

> The software that controlled the indicator light that illuminated when the two angle of attack sensors disagreed was also fixed.

I thought the issue was that the sensor-disagree warning light was not included as standard, it was sold as an optional extra. [0]

> While reviewing the software systems, a number of other software issues were found.

Interesting, I wasn't aware of that. If I understand correctly these issues aren't thought to have a direct bearing on the crashes.

[0] https://www.nytimes.com/2019/05/05/business/boeing-737-max-w...

Exactly. People seem to have skipped the V&V lectures. The code did exactly what it was asked to do. But the system/aero engineers made that decision. Even the lights issue was specified that way in the system diagram.

But the biggest defect was the decision that the pilots didn't have to be told about the risk (to avoid retraining and certification costs). If they had been told the pilots/airlines may well have protested about the lack of redundancy. All those higher ups in Boeing and the FAA should be in prison.

I don't think that is the case - but that is certainly one interpretation of it. They were still engineers at the time though, and so are we.

Given software engineering is less than 200 years old while civil engineering is a few thousand years old, I don't see this as a negative at all.

Reply on news.ycombinator.com