kayo_20211030 9 hours 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.

▲

atrettel 6 hours ago | parent | next [-]

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

	▲	kayo_20211030 5 hours ago \| parent [-]
		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.

▲

wheelinsupial 2 hours ago | parent | prev | next [-]

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

▲

glitchc 6 hours ago | parent | prev | next [-]

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 5 hours ago | parent | next [-]

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 5 hours ago | parent | prev [-]

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.

	▲	kayo_20211030 4 hours ago \| parent \| next [-]
		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.
	▲	pixl97 4 hours ago \| parent \| prev [-]
		>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.

▲

whstl 5 hours ago | parent | prev | next [-]

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

	▲	RaftPeople 4 hours ago \| parent \| next [-]
		> Nah, those changes are only in the surface, at the most shallow level. Very strongly disagree. There are limitless methods of solving problems with software (due to very few physical constraints) and there are an enormous number of different measures of whether it's "good" or "bad". It's both the blessing and curse of software.
	▲	kayo_20211030 5 hours ago \| parent \| prev [-]
		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.

▲

bitwize 2 hours ago | parent | prev [-]

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.