"Engineering isn’t like computer programming - if you get bridge design concept wrong people can be seriously injured or massive financial damage can occur."
I always hear this, but it merely suggests the speaker has never worked on a mission critical software system ;-)
That's a great point, Zach. Let's not discount the work of those software engineers! Do you know if these programmers have similar approvals workflows and rigorous technical requirements to bridge engineers?
Hey Luke, sorry I think my comment sounded snarkier than intended. Love the idea of open sourcing non-software fields. I didn't realize other areas of engineering were so "closed source".
I think software and physical engineering are both surely difficult, but perhaps in different ways?
For example, some argue that software systems are inherently more complex than physical systems because of the malleability in the domain and the interdependencies in the system.
Here's Frederick Brooks:
> Software entities are more complex for their size than perhaps any other human construct, because no two parts are alike (at least above the statement level). If they are, we make the two similar parts into one, a subroutine, open or closed. In this respect software systems differ profoundly from computers, buildings, or automobiles, where repeated elements abound.
> Digital computers are themselves more complex than most things people build; they have very large numbers of states. This makes conceiving, describing, and testing them hard. Software systems have orders of magnitude more states than computers do.
> Whereas a "brick is a brick is a brick" in, say, while constructing a house, it's not the case that "a variable is a variable is a variable" or "a function is a function is a function".
We are not bound by the laws of physics like a bridge is. This makes software easier in a way. But it also makes it harder because complexity (and confusion) accretes:
"The greatest limitation in writing software is our ability to understand the systems we are creating" says John Ousterhout. Software systems are nearly impossible to pre-specify in detail in the same way that a blueprint for a house is pre-specified. This is why software engineering feels sloppy and iterative compared to real engineering :-)
Or maybe this happens in structural engineering too?
Production software systems definitely have approval workflows and rigorous technical requirements. They are probably not rigorous in the same way as the stress tests and inspections of a bridge.
But software engineers use tools like fuzzers (which throw "noise" at a system) and enormous suites of automated tests that simulate failure modes in a similar way that I imagine structural engineers simulate physical failure modes.
It's true that, if a software system fails, cars won't fall into the ocean. But you may leak a million people's private health information and create a company-destroying lawsuit. Or you might lose millions of dollars, as has happened to software-heavy hedge funds many times. Or, as in the case of hardware-embedded software or statistical algorithms, you might cause a train or car to crash, or authorize the wrong organ transplant, or send someone to prison unjustly.
It's great that you point out how critical the work of software engineers can be to society. The comment in the article was a throwaway line about expected resistance to the "open source" approach.
I don't want to get into the weeds of which is more complicated (I think they both have their moments and differences).
The point is to highlight that I think there would be a tonne of value, both for the structural engineering community and the individual, of adopting a more open-sourced approach.
I apologize for being unable to subscribe yet but appreciate that you have a blog (if I hear of any future engineering students I'll direct her or him to your site.) I've had the Civil Engineering app by Softecks for a while
Graphisoft's Building Together 3 day classes {2022} were amazing !
"Engineering isn’t like computer programming - if you get bridge design concept wrong people can be seriously injured or massive financial damage can occur."
I always hear this, but it merely suggests the speaker has never worked on a mission critical software system ;-)
That's a great point, Zach. Let's not discount the work of those software engineers! Do you know if these programmers have similar approvals workflows and rigorous technical requirements to bridge engineers?
Hey Luke, sorry I think my comment sounded snarkier than intended. Love the idea of open sourcing non-software fields. I didn't realize other areas of engineering were so "closed source".
I think software and physical engineering are both surely difficult, but perhaps in different ways?
For example, some argue that software systems are inherently more complex than physical systems because of the malleability in the domain and the interdependencies in the system.
Here's Frederick Brooks:
> Software entities are more complex for their size than perhaps any other human construct, because no two parts are alike (at least above the statement level). If they are, we make the two similar parts into one, a subroutine, open or closed. In this respect software systems differ profoundly from computers, buildings, or automobiles, where repeated elements abound.
> Digital computers are themselves more complex than most things people build; they have very large numbers of states. This makes conceiving, describing, and testing them hard. Software systems have orders of magnitude more states than computers do.
> Whereas a "brick is a brick is a brick" in, say, while constructing a house, it's not the case that "a variable is a variable is a variable" or "a function is a function is a function".
We are not bound by the laws of physics like a bridge is. This makes software easier in a way. But it also makes it harder because complexity (and confusion) accretes:
"The greatest limitation in writing software is our ability to understand the systems we are creating" says John Ousterhout. Software systems are nearly impossible to pre-specify in detail in the same way that a blueprint for a house is pre-specified. This is why software engineering feels sloppy and iterative compared to real engineering :-)
Or maybe this happens in structural engineering too?
Production software systems definitely have approval workflows and rigorous technical requirements. They are probably not rigorous in the same way as the stress tests and inspections of a bridge.
But software engineers use tools like fuzzers (which throw "noise" at a system) and enormous suites of automated tests that simulate failure modes in a similar way that I imagine structural engineers simulate physical failure modes.
It's true that, if a software system fails, cars won't fall into the ocean. But you may leak a million people's private health information and create a company-destroying lawsuit. Or you might lose millions of dollars, as has happened to software-heavy hedge funds many times. Or, as in the case of hardware-embedded software or statistical algorithms, you might cause a train or car to crash, or authorize the wrong organ transplant, or send someone to prison unjustly.
No offense taken, Zach. :)
It's great that you point out how critical the work of software engineers can be to society. The comment in the article was a throwaway line about expected resistance to the "open source" approach.
I don't want to get into the weeds of which is more complicated (I think they both have their moments and differences).
The point is to highlight that I think there would be a tonne of value, both for the structural engineering community and the individual, of adopting a more open-sourced approach.
https://community.graphisoft.com/t5/international/ct-p/EN
I apologize for being unable to subscribe yet but appreciate that you have a blog (if I hear of any future engineering students I'll direct her or him to your site.) I've had the Civil Engineering app by Softecks for a while
Graphisoft's Building Together 3 day classes {2022} were amazing !