4 ms·

In the bridge analogy he implies that software engineering cannot be more like civil engineering due to changing requirements. He stretches the common analogy o

In the bridge analogy he implies that software engineering cannot be more like civil engineering due to changing requirements. He stretches the common analogy of building bridges by suggesting it's normal to add a car-wash to the middle of the bridge before you've finished developing it. This is the norm in software development so there's no way we can engineer a software solution with the same rigour as other, proper, engineering disciplines! I do believe software engineering can be more like civil engineering and that there are organizations around the world which will license capital-P engineers in software. Just because requirements change does not mean we cannot write mathematically precise and robust models and definitions of systems. It also doesn't mean we cannot, a priori, build software that is as robust to operating conditions as a bridge. What we're doing as an industry when we run software in production without clearly known limits is simply taking risk. We could know what the tolerable limits are of a particular server are or precisely define the probability that a given change will reach quorum within a particular bound of time. However for a good number of projects we're comfortable accepting that our customers will discover those omissions for us and no one will get hurt. However if you're writing software to control robotics that help people walk or air-flight control software to safely land multi-million dollar jets you're probably going to take more precautions to design and test your software and create detailed, precise specifications. Update: To take the bridge analogy in a different direction: it's more common in the software industry to build two bridges: the one most people use but could fall down at any time or the bridge that costs a significant amount more but there will be a small team of developers waiting to help you get up if it does. update update: The point is you can write sound models of your abstractions and prove properties about them with sufficient tooling. Much the same way that a blueprint is an abstraction of the bridge that is built, we have ways of writing blueprints of software systems.

wvenable 9y ago
I think software engineering cannot be more like civil engineering because software is the result of the decision making process. In civil engineering, the blueprint is the result of the decision making process and the bulk of time and cost is building from that blueprint. You cannot compare the process of building a bridge to building software; you could compare the process of constructing the blueprint with building software. And I think the scale of complexity of most software far exceeds the complexity of most blueprints.
- miceeatnicerice 9y ago
  No software is creatively fathomed out of nothing. Opinionated frameworks abound, pre-ordaining the little manouevres needed to wire them up properly, and solving familiar problems with established patterns. If these have all been decided beforehand, even if only by convention, then what are they but blueprints? What difference there is works in software's favour: there's a frothy top layer of most projects where developers can indulge their whims/hone their abilities and approaches. But it's not the whole.
  - wvenable 9y ago
    Physical items are built the same way; everything is built from smaller components many of which are farmed out to other providers. When you have a blueprint for a bridge you don't also plan the forging of the bolts. The parts you're talking about (in either software or bridges) are important but aren't where the design effort goes. Everything interesting in every project is in that frothy top layer.
  - Jtsummers 9y ago
    They aren't blueprints, they're foundations and components if we're going to stick to this analogy. Blueprints are specifications and design documents. Most software lacks these.
    - wvenable 9y ago
      Specifications and design documents are merely estimations. If you've made every single decision possible, you've written the software. If you have blueprints for a bridge and get two different companies to build it, you'll get the same bridge both times. The differences, if any, would be minor. If you give specifications and design documents to two software teams you could get radically different products that look nothing alike and it's entirely possible that neither one of them will satisfy the clients needs.
      - Jtsummers 9y ago
tmp234589 9y ago
I think building software is more like building a whole city for millions of people in one go. The bridge has a very simple goal, to cross from one place to another. Also you would need to speed up time a lot for it to be comparable. Imagine if technological change was so fast that by the time you finished building the bridge there were flying cars everywhere. Blueprints are not that important when you need to build something that needs to adapt. Take for example olimpic stadiums that no one uses, they might have good blueprints and all the regulations but who cares now they are still useless. On the other hand take the exampole of haussman buildings in paris they are still being used and proved very adaptable. I guess it might have something to do with nassim taleb's concept of antifragility. Software is very rapidly proved to be fragile because it operates in a context where there are a lot of black swans. On the contrary bridges operate on another time scale wher it might not be so obvious how fragile they are but given the correct scale you would have bridge builders facing the same problems as software developers. [edit] Also you need to take into account the crazy fact that you build software based on some facts but the software you build changes those facts, so now you need to change the software that will change the facts so on and so forth.

wvenable 9y ago

I think software engineering cannot be more like civil engineering because software is the result of the decision making process. In civil engineering, the blueprint is the result of the decision making process and the bulk of time and cost is building from that blueprint. You cannot compare the process of building a bridge to building software; you could compare the process of constructing the blueprint with building software. And I think the scale of complexity of most software far exceeds the complexity of most blueprints.

miceeatnicerice 9y ago
No software is creatively fathomed out of nothing. Opinionated frameworks abound, pre-ordaining the little manouevres needed to wire them up properly, and solving familiar problems with established patterns. If these have all been decided beforehand, even if only by convention, then what are they but blueprints? What difference there is works in software's favour: there's a frothy top layer of most projects where developers can indulge their whims/hone their abilities and approaches. But it's not the whole.
- wvenable 9y ago
  Physical items are built the same way; everything is built from smaller components many of which are farmed out to other providers. When you have a blueprint for a bridge you don't also plan the forging of the bolts. The parts you're talking about (in either software or bridges) are important but aren't where the design effort goes. Everything interesting in every project is in that frothy top layer.
- Jtsummers 9y ago
  They aren't blueprints, they're foundations and components if we're going to stick to this analogy. Blueprints are specifications and design documents. Most software lacks these.
  - wvenable 9y ago
    Specifications and design documents are merely estimations. If you've made every single decision possible, you've written the software. If you have blueprints for a bridge and get two different companies to build it, you'll get the same bridge both times. The differences, if any, would be minor. If you give specifications and design documents to two software teams you could get radically different products that look nothing alike and it's entirely possible that neither one of them will satisfy the clients needs.
    - Jtsummers 9y ago

tmp234589 9y ago

I think building software is more like building a whole city for millions of people in one go. The bridge has a very simple goal, to cross from one place to another. Also you would need to speed up time a lot for it to be comparable. Imagine if technological change was so fast that by the time you finished building the bridge there were flying cars everywhere. Blueprints are not that important when you need to build something that needs to adapt. Take for example olimpic stadiums that no one uses, they might have good blueprints and all the regulations but who cares now they are still useless. On the other hand take the exampole of haussman buildings in paris they are still being used and proved very adaptable. I guess it might have something to do with nassim taleb's concept of antifragility. Software is very rapidly proved to be fragile because it operates in a context where there are a lot of black swans. On the contrary bridges operate on another time scale wher it might not be so obvious how fragile they are but given the correct scale you would have bridge builders facing the same problems as software developers. [edit] Also you need to take into account the crazy fact that you build software based on some facts but the software you build changes those facts, so now you need to change the software that will change the facts so on and so forth.