4 ms·

I think software engineering cannot be more like civil engineering because software is the result of the decision making process. In civil engineering, the blu

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
      If they don't meet the clients needs then they were the wrong spec and design document. Honest question: without a specification, how do you verify your software?
      - wvenable 9y ago
        There is plenty of software that is driven entirely by specification. Inputs come in and outputs go out. And you validate that with a test suite, etc. But even more software is designed not for machine-machine communication but for machine-human interaction. And humans are notoriously bad at knowing what they want and need. In some cases, the existence of software so fundamentally changes the nature of work that humans don't even have the frame of reference necessary to provide full specifications. Yet the software still has to be written, do it's job, and be accepted. I'm not sure I have an answer to your question but somehow I still get the job done.
    - agentultra 9y ago
      Given a formal model or proof of a system and the two teams will either succeed or fail. Give them a specification in prose and they will have a little too much wiggle room. Such specifications are useful to a degree but I look at them like sketches on a napkin. If you use a more formal method of mathematics as your specification then you can be more precise about the invariants that matter and model your system more faithfully. And with a good proof assistant or model checker the computer can even help you catch flaws in your design that you would never have been able to think of on your own. It's true that the source code is a proof of something. It often helps to know whether you've built the right thing. And that it does what you think it does.
nly 9y ago
The other thing is, when you build physical things the way you do things is constrained by, well, physics. Nobody goes and builds an MVP Golden Gate Bridge and then just shores it up in production or piles crap on top of it, and anybody with a shred of sense builds a solid foundation before they go and put up a skyscraper. In software it's too easy to get things in to working state that are hanging by a thread.
- agentultra 9y ago
  Surprise you're programming a machine that is governed by physics! Want to render that scene on that PS4 console over there at 60 fps? Well that disc drive can only read bytes so fast and you have to update the physics simulation before all those effects are applied... 60 times per second. Physics. There is enough useful stuff in first-order and temporal logic for dealing with all of the challenges that specifying systems with the given properties and level of confidence that blueprints give us.
agentultra 9y ago
And that's why we need good tools for reasoning about and specifying systems. Amazon and Microsoft seem to trust TLA+ for designing some of the most complex systems in production today. I'm pretty sure they wouldn't have pulled it off without formal methods (Amazon released a paper about their use of TLA+ and MS has mentioned it's role in the development of Cosmos). Software systems can be specified using precise, robust blueprints. Those blueprints are expressed in math and I believe from my own experience that they are immensely useful.

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
    If they don't meet the clients needs then they were the wrong spec and design document. Honest question: without a specification, how do you verify your software?
    - wvenable 9y ago
      There is plenty of software that is driven entirely by specification. Inputs come in and outputs go out. And you validate that with a test suite, etc. But even more software is designed not for machine-machine communication but for machine-human interaction. And humans are notoriously bad at knowing what they want and need. In some cases, the existence of software so fundamentally changes the nature of work that humans don't even have the frame of reference necessary to provide full specifications. Yet the software still has to be written, do it's job, and be accepted. I'm not sure I have an answer to your question but somehow I still get the job done.
  - agentultra 9y ago
    Given a formal model or proof of a system and the two teams will either succeed or fail. Give them a specification in prose and they will have a little too much wiggle room. Such specifications are useful to a degree but I look at them like sketches on a napkin. If you use a more formal method of mathematics as your specification then you can be more precise about the invariants that matter and model your system more faithfully. And with a good proof assistant or model checker the computer can even help you catch flaws in your design that you would never have been able to think of on your own. It's true that the source code is a proof of something. It often helps to know whether you've built the right thing. And that it does what you think it does.

nly 9y ago

The other thing is, when you build physical things the way you do things is constrained by, well, physics. Nobody goes and builds an MVP Golden Gate Bridge and then just shores it up in production or piles crap on top of it, and anybody with a shred of sense builds a solid foundation before they go and put up a skyscraper. In software it's too easy to get things in to working state that are hanging by a thread.

agentultra 9y ago
Surprise you're programming a machine that is governed by physics! Want to render that scene on that PS4 console over there at 60 fps? Well that disc drive can only read bytes so fast and you have to update the physics simulation before all those effects are applied... 60 times per second. Physics. There is enough useful stuff in first-order and temporal logic for dealing with all of the challenges that specifying systems with the given properties and level of confidence that blueprints give us.

agentultra 9y ago

And that's why we need good tools for reasoning about and specifying systems. Amazon and Microsoft seem to trust TLA+ for designing some of the most complex systems in production today. I'm pretty sure they wouldn't have pulled it off without formal methods (Amazon released a paper about their use of TLA+ and MS has mentioned it's role in the development of Cosmos). Software systems can be specified using precise, robust blueprints. Those blueprints are expressed in math and I believe from my own experience that they are immensely useful.