4 ms·

This is your reminder that buildings and software are not that dissimilar. Remember this news article whenever you hear someone blathering about how building so

by pnathan 13y ago

This is your reminder that buildings and software are not that dissimilar. Remember this news article whenever you hear someone blathering about how building software should be more like civil engineering.

acomjean 13y ago
As a former Civil Engineer, I can say that software is not anything like Civil Engineering. The consequences of software failure are (usually) significantly less and oddly you can't practice Civil Engineering in the US without a license. There are some similarities as they both are designing a building stuff. Software is significantly easier to test however.
- jacques_chester 13y ago
  On the other hand, we can't just add more code to increase our safety margin. I read a book[1] about civil & structural engineering that made me think that perhaps we software engineers should stop fetishising what is a quite different, but still quite uncertain, profession. [1] http://chester.id.au/2013/07/07/review-to-engineer-is-human-the-role-of-failure-in-successful-design/ http://chester.id.au/2013/07/07/review-to-engineer-is-human-...
- pnathan 13y ago
  Okay, I defer to you. :-) So there's this meme floating around that software "engineering" needs to be more like "real engineering". "Real Engineering" doesn't make mistakes, has everything planned, is on time, is reliable, etc (don't laugh, OK? This is the meme, not the truth). It's fairly foolish, and I want to point out the reality. N.b., I personally don't think writing software is engineering (no laws of physics, no experimental results, no materials, no models of behavior - I can go considerably more in depth if someone cares enough to email me); I see it as a craft.
  - Dwolb 13y ago
    Software is definitely engineering for real time and safety applications. Consider aerospace software that keeps planes flying, drive-by-wire systems, and power plant software
    - pnathan 13y ago
      I've done SW for real-time & safety critical systems. Things are heavily tilted towards "Quality" in the "quality fast cheap" triangle there, but at the end of the day, it's still: - unit tests - functional tests - code reviews - automated analysis tools I have a real hard time saying that this is engineering when it can be done by anyone who has the internal discipline to do it carefully. More pertinently, I don't believe that there's any experimental basis to demonstrate software's correctness for a task a priori. E.g., I (or actually a more competent mechanical engineer) can develop a model for a table and demonstrate that given x,y,z constraints the table will hold; attaining x,y,z constraints requires using a,b,c kinds of materials. This all before the table has been built, based on fundamental laws of physics and observed qualities of materials from the field of material science. Computer science research (in broad strokes) is generally devoted to determining existence or other qualities of algorithms for tasks, or demonstrating really spiffy and unthought capabilities of computers given extant algorithms and hardware. This does not generate the basis for building materials for programs: this generates tools and other capabilities to shape the software. I am not knocking CS research - it's valuable when done well. But I have a hard time seeing how CS research provides the same type of foundation that, say, chemistry research provides. What I think I am saying is that formal sciences don't lead to engineering the same way natural sciences do: the application is qualitatively and distinctly different, and not simply in degree or seriousness. Disagreements are invited.
- InclinedPlane 13y ago
  Software is just as difficult to test because there are combinatorially increasing numbers of possible configurations and interactions in complex systems and software can potentially have an astronomically large number of interacting components. Additionally, software defects can and do kill people and cause billions of dollars in damage. A bug in the software for the Thorac-25 radiation therapy machine killed 5 people, for example. A bug in the engine control software of a Chinook helicopter led to a crash and the deaths of 29 British soldiers. During the Cold War software and systems errors almost caused the onset of a full-scale nuclear exchange between the US and USSR at least twice. It's difficult for consequences to get higher than that.

by pnathan 13y ago

acomjean 13y ago

As a former Civil Engineer, I can say that software is not anything like Civil Engineering. The consequences of software failure are (usually) significantly less and oddly you can't practice Civil Engineering in the US without a license. There are some similarities as they both are designing a building stuff. Software is significantly easier to test however.

jacques_chester 13y ago
On the other hand, we can't just add more code to increase our safety margin. I read a book[1] about civil & structural engineering that made me think that perhaps we software engineers should stop fetishising what is a quite different, but still quite uncertain, profession. [1] http://chester.id.au/2013/07/07/review-to-engineer-is-human-the-role-of-failure-in-successful-design/ http://chester.id.au/2013/07/07/review-to-engineer-is-human-...
pnathan 13y ago
Okay, I defer to you. :-) So there's this meme floating around that software "engineering" needs to be more like "real engineering". "Real Engineering" doesn't make mistakes, has everything planned, is on time, is reliable, etc (don't laugh, OK? This is the meme, not the truth). It's fairly foolish, and I want to point out the reality. N.b., I personally don't think writing software is engineering (no laws of physics, no experimental results, no materials, no models of behavior - I can go considerably more in depth if someone cares enough to email me); I see it as a craft.
- Dwolb 13y ago
  Software is definitely engineering for real time and safety applications. Consider aerospace software that keeps planes flying, drive-by-wire systems, and power plant software
  - pnathan 13y ago
    I've done SW for real-time & safety critical systems. Things are heavily tilted towards "Quality" in the "quality fast cheap" triangle there, but at the end of the day, it's still: - unit tests - functional tests - code reviews - automated analysis tools I have a real hard time saying that this is engineering when it can be done by anyone who has the internal discipline to do it carefully. More pertinently, I don't believe that there's any experimental basis to demonstrate software's correctness for a task a priori. E.g., I (or actually a more competent mechanical engineer) can develop a model for a table and demonstrate that given x,y,z constraints the table will hold; attaining x,y,z constraints requires using a,b,c kinds of materials. This all before the table has been built, based on fundamental laws of physics and observed qualities of materials from the field of material science. Computer science research (in broad strokes) is generally devoted to determining existence or other qualities of algorithms for tasks, or demonstrating really spiffy and unthought capabilities of computers given extant algorithms and hardware. This does not generate the basis for building materials for programs: this generates tools and other capabilities to shape the software. I am not knocking CS research - it's valuable when done well. But I have a hard time seeing how CS research provides the same type of foundation that, say, chemistry research provides. What I think I am saying is that formal sciences don't lead to engineering the same way natural sciences do: the application is qualitatively and distinctly different, and not simply in degree or seriousness. Disagreements are invited.
InclinedPlane 13y ago
Software is just as difficult to test because there are combinatorially increasing numbers of possible configurations and interactions in complex systems and software can potentially have an astronomically large number of interacting components. Additionally, software defects can and do kill people and cause billions of dollars in damage. A bug in the software for the Thorac-25 radiation therapy machine killed 5 people, for example. A bug in the engine control software of a Chinook helicopter led to a crash and the deaths of 29 British soldiers. During the Cold War software and systems errors almost caused the onset of a full-scale nuclear exchange between the US and USSR at least twice. It's difficult for consequences to get higher than that.