5 ms·

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 ha

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

cobbzilla 6y ago
The sarcastic/negative implication of your example is that software engineering today is where civil engineering was 100+ years ago.
- nickpeterson 6y 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
  - m_mueller 6y ago
    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?
  - MaxBarraclough 6y ago
    > 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.
- nomoreusernames 6y ago
  made me chuckle.
- piaste 6y ago
  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.
  - MaxBarraclough 6y ago
    > 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.
  - LoSboccacc 6y ago
    > 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)
    - deleted 6y ago
      [deleted]
    - MaxBarraclough 6y ago
      The 737 Max issues were not with the software.
      - fsflyer 6y ago
- zanellato19 6y ago
  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.
- elros 6y ago
  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.
ku-man 6y ago
There are definitely several ancient and recent cases of bad design or execution in civil/mechanical/chemical engineering. The difference is that there is a very strict regulatory body that reviews and sanctions such malpractices (not to mention the exams you need to write to become a member of such bodies). Unfortunately, when it comes to software development we have people who modify wordpress templates and call themselves engineers... I cringe whenever I read about the new 'engineering disciplines' such as 'react engineer' or 'dev-ops engineer' or 'gis engineer'.
Karellen 6y ago
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.
- zanellato19 6y ago
  > 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.
  - bigbubba 6y ago
    A thief thinks every man steals. An apathetic engineer thinks all engineers share his apathy.

cobbzilla 6y ago

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

nickpeterson 6y 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
- m_mueller 6y ago
  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?
- MaxBarraclough 6y ago
  > 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.
nomoreusernames 6y ago
made me chuckle.
piaste 6y ago
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.
- MaxBarraclough 6y ago
  > 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.
- LoSboccacc 6y ago
  > 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)
  - deleted 6y ago
    [deleted]
  - MaxBarraclough 6y ago
    The 737 Max issues were not with the software.
    - fsflyer 6y ago
zanellato19 6y ago
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.
elros 6y ago
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.

ku-man 6y ago

There are definitely several ancient and recent cases of bad design or execution in civil/mechanical/chemical engineering. The difference is that there is a very strict regulatory body that reviews and sanctions such malpractices (not to mention the exams you need to write to become a member of such bodies). Unfortunately, when it comes to software development we have people who modify wordpress templates and call themselves engineers... I cringe whenever I read about the new 'engineering disciplines' such as 'react engineer' or 'dev-ops engineer' or 'gis engineer'.

Karellen 6y ago

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.

zanellato19 6y ago
> 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.
- bigbubba 6y ago
  A thief thinks every man steals. An apathetic engineer thinks all engineers share his apathy.