3 ms·

+1 Software engineering is still an immature field. Civil engineers have known how to build a bridge that won't fall down for about 2000 years. We still have

by j_baker 17y ago

+1 Software engineering is still an immature field. Civil engineers have known how to build a bridge that won't fall down for about 2000 years. We still haven't figured out how to write software that doesn't break.

jodrellblank 17y ago
Emergency safety reviews on 1,800 bridges in a region of the UK recently because they got wet: http://news.bbc.co.uk/1/hi/uk/8372775.stm http://news.bbc.co.uk/1/hi/uk/8372775.stm Yes people know how to build bridges that don't collapse arbitrarily, and people know how to build software that doesn't crash arbitrarily - when it's simple enough and exposed to a limited range of inputs and is built on a solid foundation. Most software changes as it's used - bridges don't. A bridge never falls down because a lorry drives onto it, then goes into suspend mode because the battery runs low, then when it wakes up the lorry has gone without driving off the end. A bridge never has a painter working on it who then has to make their changes live and accidentally makes one of the lanes invisible. When you put too many concurrent requests into a web server nobody can use it and they are stuck, with a bridge it's an everyday traffic jam and people see it long in advance and know detours around it and gets on with their lives. If bridges were as complex as software, would they still be as reliable?
- wallflower 17y ago
  > If bridges were as complex as software, would they still be as reliable? No. As a simple example, if there are n software modules, there are n! possible communication paths. Yes, black-boxing can partition n down but software is not self-healing (yet). Witness the GMail cascading failures. The bridge supports were undermined because the high-water level flooding generated enormous hydrostatic pressure against the footings (pressure is greatest at the bottom - where the footings meet the earth). Think of standing in the surf and getting knocked down by a wave - the force, whether you know it or not, is greatest at the bottom (near your feet - which is why you can lose your footing). http://www.csus.edu/indiv/h/hollandm/ce135/Viewgrph/SluicGat/sggraphs/sluicemomentum.gif http://www.csus.edu/indiv/h/hollandm/ce135/Viewgrph/SluicGat... http://www.csus.edu/indiv/h/hollandm/ce135/Viewgrph/SluicGat/SGViewGr.htm http://www.csus.edu/indiv/h/hollandm/ce135/Viewgrph/SluicGat...
  - hxa7241 17y ago
    I am not sure how to measure and compare complexity of buildings and software. But I wouldn't immediately dismiss buildings as being all simpler than all software. > if there are n software modules, there are n! possible communication paths. We deliberately build software so it does not join every part to every other. That is fairly evident from top to bottom, and really it couldn't have a distinct coherent function if that wasn't the case. So I think a stronger argument is needed . . . which I would be quite willing to accept if good . . .
    - wallflower 17y ago
      Good questions. I tried to answer your question by replying to your other comment a few minutes ago. The answer to your question lies in the idea that the more software can adhere to rules (assertions, aspects, closures) the more rule-driven the virtual model+behavior the software will have. Rules are good. It's good that we always fall towards the ground. It's bad a buffer overflow or exception will gum up a running software process.

by j_baker 17y ago

jodrellblank 17y ago

Emergency safety reviews on 1,800 bridges in a region of the UK recently because they got wet: http://news.bbc.co.uk/1/hi/uk/8372775.stm http://news.bbc.co.uk/1/hi/uk/8372775.stm Yes people know how to build bridges that don't collapse arbitrarily, and people know how to build software that doesn't crash arbitrarily - when it's simple enough and exposed to a limited range of inputs and is built on a solid foundation. Most software changes as it's used - bridges don't. A bridge never falls down because a lorry drives onto it, then goes into suspend mode because the battery runs low, then when it wakes up the lorry has gone without driving off the end. A bridge never has a painter working on it who then has to make their changes live and accidentally makes one of the lanes invisible. When you put too many concurrent requests into a web server nobody can use it and they are stuck, with a bridge it's an everyday traffic jam and people see it long in advance and know detours around it and gets on with their lives. If bridges were as complex as software, would they still be as reliable?

wallflower 17y ago
> If bridges were as complex as software, would they still be as reliable? No. As a simple example, if there are n software modules, there are n! possible communication paths. Yes, black-boxing can partition n down but software is not self-healing (yet). Witness the GMail cascading failures. The bridge supports were undermined because the high-water level flooding generated enormous hydrostatic pressure against the footings (pressure is greatest at the bottom - where the footings meet the earth). Think of standing in the surf and getting knocked down by a wave - the force, whether you know it or not, is greatest at the bottom (near your feet - which is why you can lose your footing). http://www.csus.edu/indiv/h/hollandm/ce135/Viewgrph/SluicGat/sggraphs/sluicemomentum.gif http://www.csus.edu/indiv/h/hollandm/ce135/Viewgrph/SluicGat... http://www.csus.edu/indiv/h/hollandm/ce135/Viewgrph/SluicGat/SGViewGr.htm http://www.csus.edu/indiv/h/hollandm/ce135/Viewgrph/SluicGat...
- hxa7241 17y ago
  I am not sure how to measure and compare complexity of buildings and software. But I wouldn't immediately dismiss buildings as being all simpler than all software. > if there are n software modules, there are n! possible communication paths. We deliberately build software so it does not join every part to every other. That is fairly evident from top to bottom, and really it couldn't have a distinct coherent function if that wasn't the case. So I think a stronger argument is needed . . . which I would be quite willing to accept if good . . .
  - wallflower 17y ago
    Good questions. I tried to answer your question by replying to your other comment a few minutes ago. The answer to your question lies in the idea that the more software can adhere to rules (assertions, aspects, closures) the more rule-driven the virtual model+behavior the software will have. Rules are good. It's good that we always fall towards the ground. It's bad a buffer overflow or exception will gum up a running software process.