8 ms·
I think the points they're making are all valid and I share the concerns outlined, but I disagree more than I agree. Bridges have collapsed, buildings have fai
by karamanolev 5y ago
I think the points they're making are all valid and I share the concerns outlined, but I disagree more than I agree.
Bridges have collapsed, buildings have failed, but that happens less than software crashes. Why is that? I think the most important differentiator is the tolerance for such failures. Software is written cheaply, quickly and fails more often because we can afford it to. If we could afford the same thing with buildings, they'd be made quickly and cheaply, but our societal tolerance for that is much lower.
I posit that software can be made to the same high standards as buildings or bridges, but it would have to be much simpler and/or way more expensive. So why not call software developers engineers? Just like structural engineers, we have to meet a quality bar set by mostly external circumstances. Is it the lack of industry certification? That would've happened, if the consequences of failing to meet the bar were the same or worse.
- inglor_cz 5y agoSoftware flaws are more abstract and hard to detect. While a material crack will show on an X-ray image, a security flaw in an authentication code may be subtle enough that no tool will be able to highlight it.
- detaro 5y agoI don't think that is a good distinction. Mechanical engineering was engineering long before it had todays tools and understanding of material (which is constantly expanding). Software engineering is driving forward the equivalent developments, but is just younger as a field. Software development as a field does struggle with adopting these tools, but I think that's a matter of degree, not fundamental. The roles are not as cleanly defined yet, what counts as engineering work and what as "just" implementation.
- seumars 5y agoThe thing is, buildings are being built cheaply but most people can’t afford to make a different choice: https://twitter.com/dreamboatslim/status/1382282414374932482 https://twitter.com/dreamboatslim/status/1382282414374932482
- dasil003 5y agoI think the most important differentiator is that the function of a bridge is extremely simple, a good design has very clear success criteria, and the materials and physics underlying them do not change. That's not to say it's easy, but rather that we've had thousands of years of practice and refinement without moving the goal posts. Contrast with software: Many large software projects fail to even achieve a coherent and feasible high-level spec of what the system needs to do, let alone how all the details will work. Once you get past that phase, you find that the actual design and build of software systems relies on so many layers of abstraction that practitioners have to make a lot of assumptions in order to get anything done. In practice it works because we tend to keep the lower levels stable and coalesce around a relatively small number of proven stacks, but unlike the hard engineers knowledge of materials and physics, the actual platforms are all human defined and subject to change. Imagine how civic engineering would work if physics were just code written by humans that never stopped monkeying with it.
- alboy 5y agoExactly, nobody makes a fuss about packaging engineers because the milk cartons they design cannot stop shrapnel. Making a design that is good enough for the users' expectations while being significantly faster and cheaper to manufacture than the alternative ones is what engineers do.
- tdeck 5y agoPackaging engineers are a great example. Clearly the standards in that profession haven't made "press here to open" a trustworthy instruction.
- 7thaccount 5y agoI'm not sure who actually designs packaging material. I mean, I've never heard of a packaging engineering degree. A company designing packaging might hire structural (sub field of civil) or mechanical engineers I guess. If so, that means they're an engineer in my book.
- hilbert42 5y agoYou should read this 1994 SciAm article (Software's Chronic Crisis, SciAm, September 1994). There are many copies of it on the web. It's old but it's still the best summary of the problem as it puts the software issue into context with other fields of engineering. These links were the first I found and they've tested OK. The first is an html version, the others are PDFs with the last being the best quality (in color). If they don't work just search for the title and year. http://users.csc.calpoly.edu/~jdalbey/SWE/Papers/SciAmGibbs/SciAmGibbs.html http://users.csc.calpoly.edu/~jdalbey/SWE/Papers/SciAmGibbs/... http://sarec.nd.edu/courses/SE2017/Week1-TheSoftwareCrisis.pdf http://sarec.nd.edu/courses/SE2017/Week1-TheSoftwareCrisis.p... https://www.researchgate.net/profile/Wayt-Gibbs/publication/247573088_Software's_Chronic_Crisis/links/0046353b4cb57cc197000000/Softwares-Chronic-Crisis.pdf https://www.researchgate.net/profile/Wayt-Gibbs/publication/...