5 ms·

> I don’t know if structural engineering works like this, but I do know that software engineering doesn’t. Structural Engineering (generally construction engin

by kayo_20211030 10mo ago

> I don’t know if structural engineering works like this, but I do know that software engineering doesn’t. Structural Engineering (generally construction engineering) does work like that. Following the analogy, the engineers draw; they don't lay bricks. But, all the best engineers have probably been site supervisors at some point and have watched brick being layed, and spoken to the layers of bricks, etc. Construction methods change, but they don't change as quickly as software engineering methods. There is also a very material and applicable "reality" constraint. Most struct's knowledge/heuristics remains valid over long periods of time. The software engineers' body of knowledge can change 52 times in a year. To completely stretch the analogy - the site conditions for construction engineering are better known than the site conditions for a large software project. In the latter case the site itself can be adjusted more easily, and more materially, by the engineering itself i.e. the ground can move under your feet. Site conditioning on steroids! Ultimately, that's why I agree fully with the piece. Generic advise may be helpful, but it always applies to some generic site conditions that are less relevant in practice.

glitchc 10mo ago
It sounds like you are making the argument that there is no established way to generate good software. If that's the case, then software isn't engineering, but rather art. The former requires established/best practices to be called a discipline, while the latter is a creative endeavour.
- kayo_20211030 10mo ago
  That's true. I do. I consider it a creative art, with some disciplinary adjacency to engineering. The creative sculptor has to know the material stone in order to make anything good with it. But, construction engineering is creative too; just different.
- Scarblac 10mo ago
  I think we know how to reliably make good software. E.g. NASA manages. The problem is that doing it like that is much too expensive and too slow for most businesses.
  - pixl97 10mo ago
    >and too slow for most businesses. A lot of this is because while a 'good' business is waiting for the 'good' software to be written, some crappy business has already written the crappy software and sold it to all the customers you were depending on. In general customers are very bad at knowing the difference between good and bad software and typically buy what looks flashy or the sales people bribe them the most for.
  - kayo_20211030 10mo ago
    NASA is a bit of an outlier. In the 50's through the 70's any failure, particularly a failure involving the loss of a life, would have been a national catastrophe; a blow to national prestige. So, they were super careful that it didn't happen. The spent-cost was irrelevant compared to the reputational value at stake. Honestly, it was a wise investment given the operative quid pro quo in those days. Maybe they still do good software, I don't know, but I suspect that the value at risk today makes them more cost averse, and less sensitive to poor software. "Business" runs the same calculations. I'd posit that, as a practical matter, most businesses don't want "good" software; they want "good enough" software.
atrettel 10mo ago
Reading that particular section made me think of the tree swing cartoon [1]. I agree that the best engineers have likely been on the ground making concrete changes at some point, watching bricks being laid as you said, but I have encountered quite a few supervisors who seemingly had no idea how things were being implemented on the ground. As the post says, people on the ground then sometimes have to figure out how to implement the plan even if it ignores sound design principles. I don't view that as a failure of abstraction as a design principle as much as it is a pitfall of using the wrong abstraction. Using the right abstraction requires on the ground knowledge, and if nobody communicates that up the chain, well, you get the tree swing cartoon. [1] https://en.wikipedia.org/wiki/Tree_swing_cartoon https://en.wikipedia.org/wiki/Tree_swing_cartoon
- kayo_20211030 10mo ago
  I agree with you. But, talk too long or too fulsomely about "abstractions" or "principles" and you'll lose the brick layers. They're paid by the course, generally. Trust them to make the site adjustments, but always verify that it's not a bad-bad-thing.
whstl 10mo ago
> The software engineers' body of knowledge can change 52 times in a year Nah, those changes are only in the surface, at the most shallow level. There's always new techniques, materials and tools in structural engineering as well. Foundations take a lifetime to change.
- kayo_20211030 10mo ago
  Respectfully, I disagree. You're correct on the facts, but any "new techniques, materials and tools" need to be communicated to the brick layers. That takes time and effort i.e. it all needs to be actively managed. The brick layers have to be able to work with those new techniques and materials. I don't want some of them using method #1 over here, and method #2 over there, unless I'm wholly conversant with the methods, and fully confident that it'll all mesh eventually. The system i.e. the whole shebang has to work coherently to serve its purpose.
  - whstl 10mo ago
    > Respectfully, I disagree. You're correct on the facts, but I'm fine with the disagreement if you say I'm correct. ¯\_(ツ)_/¯ > any "new techniques, materials and tools" need to be communicated to the brick layers Same for software. > That takes time and effort i.e. it all needs to be actively managed. The brick layers have to be able to work with those new techniques and materials. Same for software. > I don't want some of them using method #1 over here, and method #2 over there, unless I'm wholly conversant with the methods, and fully confident that it'll all mesh eventually. The system i.e. the whole shebang has to work coherently to serve its purpose. Same for software. Virtually every profession has a body of knowledge that's constantly getting updated. Only software engineers seem to have this faulty assumption that they must apply it all immediately. Acknowledging it's a false assumption leads to a better life.
    - kayo_20211030 10mo ago
      Then we're in violent agreement. The challenge would be to control the pace of the evolution of the body of knowledge, but more importantly, its application, to a pace that's consistent with the pace of the system you're building. > faulty assumption that they must apply it all immediately No truer word was ever said. Everyone is attracted to shiny things.
bitwize 10mo ago
My father mentored some engineering college students about 15 years ago. He came away from the experience a bit disappointed: they knew how to model a part, but not how to machine one. When he came up in the world of slide-rule-and-drafting-pencil mechanical engineering, every engineer knew, in principle at least, how to machine a part; such knowledge was necessary for good designs because a design was instructions to shop-floor personnel on how to make the part, including info like materials to be used, tolerances, tools, etc.
- imtringued 10mo ago
  In CAD you can make an arbitrarily sized hole, in the real world you can only drill holes if you have the corresponding drill bit.
wheelinsupial 10mo ago
> software engineers' body of knowledge can change 52 times in a year I understand I’m replying against the spirit of your point, but the IEEE has actually published one and it seems to get updated very slowly. https://www.computer.org/education/bodies-of-knowledge/software-engineering#about https://www.computer.org/education/bodies-of-knowledge/softw...
aidenn0 10mo ago
And when changes are made at the site, bad things can happen: https://en.wikipedia.org/wiki/Hyatt_Regency_walkway_collapse#Investigation https://en.wikipedia.org/wiki/Hyatt_Regency_walkway_collapse...

glitchc 10mo ago

It sounds like you are making the argument that there is no established way to generate good software. If that's the case, then software isn't engineering, but rather art. The former requires established/best practices to be called a discipline, while the latter is a creative endeavour.

kayo_20211030 10mo ago
That's true. I do. I consider it a creative art, with some disciplinary adjacency to engineering. The creative sculptor has to know the material stone in order to make anything good with it. But, construction engineering is creative too; just different.
Scarblac 10mo ago
I think we know how to reliably make good software. E.g. NASA manages. The problem is that doing it like that is much too expensive and too slow for most businesses.
- pixl97 10mo ago
  >and too slow for most businesses. A lot of this is because while a 'good' business is waiting for the 'good' software to be written, some crappy business has already written the crappy software and sold it to all the customers you were depending on. In general customers are very bad at knowing the difference between good and bad software and typically buy what looks flashy or the sales people bribe them the most for.
- kayo_20211030 10mo ago
  NASA is a bit of an outlier. In the 50's through the 70's any failure, particularly a failure involving the loss of a life, would have been a national catastrophe; a blow to national prestige. So, they were super careful that it didn't happen. The spent-cost was irrelevant compared to the reputational value at stake. Honestly, it was a wise investment given the operative quid pro quo in those days. Maybe they still do good software, I don't know, but I suspect that the value at risk today makes them more cost averse, and less sensitive to poor software. "Business" runs the same calculations. I'd posit that, as a practical matter, most businesses don't want "good" software; they want "good enough" software.

atrettel 10mo ago

Reading that particular section made me think of the tree swing cartoon [1]. I agree that the best engineers have likely been on the ground making concrete changes at some point, watching bricks being laid as you said, but I have encountered quite a few supervisors who seemingly had no idea how things were being implemented on the ground. As the post says, people on the ground then sometimes have to figure out how to implement the plan even if it ignores sound design principles. I don't view that as a failure of abstraction as a design principle as much as it is a pitfall of using the wrong abstraction. Using the right abstraction requires on the ground knowledge, and if nobody communicates that up the chain, well, you get the tree swing cartoon. [1] https://en.wikipedia.org/wiki/Tree_swing_cartoon https://en.wikipedia.org/wiki/Tree_swing_cartoon

kayo_20211030 10mo ago
I agree with you. But, talk too long or too fulsomely about "abstractions" or "principles" and you'll lose the brick layers. They're paid by the course, generally. Trust them to make the site adjustments, but always verify that it's not a bad-bad-thing.

whstl 10mo ago

> The software engineers' body of knowledge can change 52 times in a year Nah, those changes are only in the surface, at the most shallow level. There's always new techniques, materials and tools in structural engineering as well. Foundations take a lifetime to change.

kayo_20211030 10mo ago
Respectfully, I disagree. You're correct on the facts, but any "new techniques, materials and tools" need to be communicated to the brick layers. That takes time and effort i.e. it all needs to be actively managed. The brick layers have to be able to work with those new techniques and materials. I don't want some of them using method #1 over here, and method #2 over there, unless I'm wholly conversant with the methods, and fully confident that it'll all mesh eventually. The system i.e. the whole shebang has to work coherently to serve its purpose.
- whstl 10mo ago
  > Respectfully, I disagree. You're correct on the facts, but I'm fine with the disagreement if you say I'm correct. ¯\_(ツ)_/¯ > any "new techniques, materials and tools" need to be communicated to the brick layers Same for software. > That takes time and effort i.e. it all needs to be actively managed. The brick layers have to be able to work with those new techniques and materials. Same for software. > I don't want some of them using method #1 over here, and method #2 over there, unless I'm wholly conversant with the methods, and fully confident that it'll all mesh eventually. The system i.e. the whole shebang has to work coherently to serve its purpose. Same for software. Virtually every profession has a body of knowledge that's constantly getting updated. Only software engineers seem to have this faulty assumption that they must apply it all immediately. Acknowledging it's a false assumption leads to a better life.
  - kayo_20211030 10mo ago
    Then we're in violent agreement. The challenge would be to control the pace of the evolution of the body of knowledge, but more importantly, its application, to a pace that's consistent with the pace of the system you're building. > faulty assumption that they must apply it all immediately No truer word was ever said. Everyone is attracted to shiny things.

bitwize 10mo ago

My father mentored some engineering college students about 15 years ago. He came away from the experience a bit disappointed: they knew how to model a part, but not how to machine one. When he came up in the world of slide-rule-and-drafting-pencil mechanical engineering, every engineer knew, in principle at least, how to machine a part; such knowledge was necessary for good designs because a design was instructions to shop-floor personnel on how to make the part, including info like materials to be used, tolerances, tools, etc.

imtringued 10mo ago
In CAD you can make an arbitrarily sized hole, in the real world you can only drill holes if you have the corresponding drill bit.

wheelinsupial 10mo ago

> software engineers' body of knowledge can change 52 times in a year I understand I’m replying against the spirit of your point, but the IEEE has actually published one and it seems to get updated very slowly. https://www.computer.org/education/bodies-of-knowledge/software-engineering#about https://www.computer.org/education/bodies-of-knowledge/softw...

aidenn0 10mo ago

And when changes are made at the site, bad things can happen: https://en.wikipedia.org/wiki/Hyatt_Regency_walkway_collapse#Investigation https://en.wikipedia.org/wiki/Hyatt_Regency_walkway_collapse...