5 ms·

The author brings up a fundamental difference between traditional engineering and software engineering. In many fields, engineers sign on the dotted line and as

by rm-rf 17y ago

The author brings up a fundamental difference between traditional engineering and software engineering. In many fields, engineers sign on the dotted line and assume professional and financial liability for the correctness of their design. They have to think about things like warranty repairs, recalls, product liability lawsuits and dead citizens. They tend to design very conservatively. How many software engineers are willing to make their careers dependent on the correctness of their code? There probably are some that are. Unfortunately I've ever met them or had the privilege of hosting their applications.

wallflower 17y ago
> How many software engineers are willing to make their careers dependent on the correctness of their code? Proving program correctness is a very involved, expensive, and rigorous process. That, being said, comprehensive unit tests are a good investment in proving that code works as it should. Software cannot be engineered like a bridge. http://en.wikipedia.org/wiki/Formal_methods http://en.wikipedia.org/wiki/Formal_methods
- mfukar 17y ago
  So, do you believe that proving the structural integrity of an engineer's work is less expensive or difficult? No, they are simply built according to several, well-established, well-studied principles. Which software engineers not only lack, but are not interested in pursuing.
  - davidw 17y ago
    People have been building bridges for a lot, lot longer than they have been building software. Also, you can go on all you want about how to engineer quality stuff, but if you ignore the economics of the situation, you'll end up pricing yourself out of the market by an order of magnitude in many fields. For instance, the web or mobile phone stuff I have been working on lately: it's important that it mostly works, and is reasonably priced. The cost of making sure it never, ever has any downtime or ever fails would simply not be worth it to my customers and clients.
    - wallflower 17y ago
      > if you ignore the economics of the situation The classic software development triangle. "The iron triangle refers to the concept that of the three critical factors scope, cost, and time at least one must vary otherwise the quality of the work suffers. Nobody wants a poor quality system, otherwise why build it? Therefore the implication is that at least one of the three vertexes must be allowed to vary. The problem is that when you try to define the exact level of quality, the exact cost, the exact schedule, and the exact scope to be delivered you virtually guarantee failure because there is no room for a project team to maneuver. Software development projects often fail because the organization sets unrealistic goals for the "iron triangle" of software development: * Scope (what must be built) * Schedule (when it must be built by) * Resources (how much it must cost)" http://www.ambysoft.com/essays/brokenTriangle.html http://www.ambysoft.com/essays/brokenTriangle.html
      - davidw 17y ago
        Or the quick version: "fast, cheap, good: pick two".
    - mfukar 17y ago
      You are contradicting yourself: nobody thinks it's even remotely realistic to give assurances with 0 margin of error. Of course it's expensive, of course it's difficult. It is likewise unrealistic for traditional engineers to do so - everyone knows that buildings will eventually collapse. However, we do need some quality assurance which is more reliable than "this piece of software passes all the tests which guided its development" - which is a nonsensical statement that somehow TDD fans hail as absolute truth. It'd improve our applications and it'd improve our skills. I can't see how it's a bad idea, unless taken to the extreme.
      - davidw 17y ago
        > we do need some quality assurance which is more reliable than "this piece of software passes all the tests which guided its development" We do not necessarily need even that. The web site for the little antique bookstore in downtown Padova really doesn't - it doesn't even handle money. They're happy to get something that mostly works and fix the rare bug that does come up when it's noticed. The software responsible for safely guiding a 747 full of people into an airport at night, on the other hand, probably does something more in terms of tests/QA/provable correctness/whatever else makes it safer, even if it makes it significantly more expensive. There's no contradiction, and I wasn't talking about TDD. My point is merely that you have to consider the economics of these things, and software projects vary to the extremes in terms of their importance and impact on our lives.
  - tomjen2 17y ago
    That is because engineering is about repeating the same old shit again and again, whereas software development is new each time you do it.
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...
noodle 17y ago
depends on what kind of code we're talking about. are we talking about my code for a video sharing and live streaming website? nope. are we talking about my code on a microcontroller whose only purpose is to physically monitor and calculate a small number of things? probably, yes. there's a huge difference between the two, both in the processes behind them and the end result of the development cycle. the code on important things where lives are on the line, like a space shuttle, is simple stuff that has been tested and combed over a lot. bridges are very singular in purpose and only need to not fail at what they're supposed to do. most software needs to not fail at what its not supposed to do, as well as what it is supposed to do.
anamax 17y ago
> How many software engineers are willing to make their careers dependent on the correctness of their code? You're assuming that correctness is binary. It isn't. If you prefer, math is the only opportunity for binary correctness. Everything else is "how likely is undesired behavior" and even that is non-trivial. Every software engineer's career depends on whether her code satisfies the likelyhood for her circumstance. How do I know this? Because folks whose code doesn't satisfy the relevant likelyhood get fired (or at least moved to other activities) or their company loses the biz. Yes, software fails. If certain failures (or their likelyhood) of certain software is a problem for you, stop using it and stop paying for it. Many software failures simply aren't worth what it would cost to fix them. No - you're not entitled to software that has the likelyhood of failure that you'd like for the price that you'd like to pay.

by rm-rf 17y ago

wallflower 17y ago

> How many software engineers are willing to make their careers dependent on the correctness of their code? Proving program correctness is a very involved, expensive, and rigorous process. That, being said, comprehensive unit tests are a good investment in proving that code works as it should. Software cannot be engineered like a bridge. http://en.wikipedia.org/wiki/Formal_methods http://en.wikipedia.org/wiki/Formal_methods

mfukar 17y ago
So, do you believe that proving the structural integrity of an engineer's work is less expensive or difficult? No, they are simply built according to several, well-established, well-studied principles. Which software engineers not only lack, but are not interested in pursuing.
- davidw 17y ago
  People have been building bridges for a lot, lot longer than they have been building software. Also, you can go on all you want about how to engineer quality stuff, but if you ignore the economics of the situation, you'll end up pricing yourself out of the market by an order of magnitude in many fields. For instance, the web or mobile phone stuff I have been working on lately: it's important that it mostly works, and is reasonably priced. The cost of making sure it never, ever has any downtime or ever fails would simply not be worth it to my customers and clients.
  - wallflower 17y ago
    > if you ignore the economics of the situation The classic software development triangle. "The iron triangle refers to the concept that of the three critical factors scope, cost, and time at least one must vary otherwise the quality of the work suffers. Nobody wants a poor quality system, otherwise why build it? Therefore the implication is that at least one of the three vertexes must be allowed to vary. The problem is that when you try to define the exact level of quality, the exact cost, the exact schedule, and the exact scope to be delivered you virtually guarantee failure because there is no room for a project team to maneuver. Software development projects often fail because the organization sets unrealistic goals for the "iron triangle" of software development: * Scope (what must be built) * Schedule (when it must be built by) * Resources (how much it must cost)" http://www.ambysoft.com/essays/brokenTriangle.html http://www.ambysoft.com/essays/brokenTriangle.html
    - davidw 17y ago
      Or the quick version: "fast, cheap, good: pick two".
  - mfukar 17y ago
    You are contradicting yourself: nobody thinks it's even remotely realistic to give assurances with 0 margin of error. Of course it's expensive, of course it's difficult. It is likewise unrealistic for traditional engineers to do so - everyone knows that buildings will eventually collapse. However, we do need some quality assurance which is more reliable than "this piece of software passes all the tests which guided its development" - which is a nonsensical statement that somehow TDD fans hail as absolute truth. It'd improve our applications and it'd improve our skills. I can't see how it's a bad idea, unless taken to the extreme.
    - davidw 17y ago
      > we do need some quality assurance which is more reliable than "this piece of software passes all the tests which guided its development" We do not necessarily need even that. The web site for the little antique bookstore in downtown Padova really doesn't - it doesn't even handle money. They're happy to get something that mostly works and fix the rare bug that does come up when it's noticed. The software responsible for safely guiding a 747 full of people into an airport at night, on the other hand, probably does something more in terms of tests/QA/provable correctness/whatever else makes it safer, even if it makes it significantly more expensive. There's no contradiction, and I wasn't talking about TDD. My point is merely that you have to consider the economics of these things, and software projects vary to the extremes in terms of their importance and impact on our lives.
- tomjen2 17y ago
  That is because engineering is about repeating the same old shit again and again, whereas software development is new each time you do it.

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

noodle 17y ago

depends on what kind of code we're talking about. are we talking about my code for a video sharing and live streaming website? nope. are we talking about my code on a microcontroller whose only purpose is to physically monitor and calculate a small number of things? probably, yes. there's a huge difference between the two, both in the processes behind them and the end result of the development cycle. the code on important things where lives are on the line, like a space shuttle, is simple stuff that has been tested and combed over a lot. bridges are very singular in purpose and only need to not fail at what they're supposed to do. most software needs to not fail at what its not supposed to do, as well as what it is supposed to do.

anamax 17y ago

> How many software engineers are willing to make their careers dependent on the correctness of their code? You're assuming that correctness is binary. It isn't. If you prefer, math is the only opportunity for binary correctness. Everything else is "how likely is undesired behavior" and even that is non-trivial. Every software engineer's career depends on whether her code satisfies the likelyhood for her circumstance. How do I know this? Because folks whose code doesn't satisfy the relevant likelyhood get fired (or at least moved to other activities) or their company loses the biz. Yes, software fails. If certain failures (or their likelyhood) of certain software is a problem for you, stop using it and stop paying for it. Many software failures simply aren't worth what it would cost to fix them. No - you're not entitled to software that has the likelyhood of failure that you'd like for the price that you'd like to pay.