> And to your point, if anyone ever asked an engineer to insert another floor between 8th and 9th floor of a 15 story building, they'd laugh at them. In software engineering, this is possible even if hard.
Ah yes, another cocktail party idea [1] where a software engineer pretends like they understand civil engineering.
I really think you should read Dan's post in full. Because you really did make the error him and Hillel discuss. I think it'll also help interpret my point and the gp to my comment. We're not thinking in a framework where CS and Eng are all that different.
Or skip to this part of Hillel's video[0]
I've been an aerospace engineer. Worked there before coming over to CS. And I can certainty tell you that yes, someone may ask you to split a floor in half. There's nothing really preventing you from doing this. There's buildings with more levels than there are ordered floors. It's a 15 floor building, but you label your floors 1-14. Such an area can be used for things like running conduit or even just as a fire break. Hell, there are even split level homes, you know those ones where you walk in the front door and either go up or down? There's also things like scissor flats.
So yeah, you are making the mistake because your example belies you. It illustrates that you aren't aware of the complexities and abstractions in the engineering job. It's okay to have only a rudimentary understanding of engineering, you've spent your time learning other things that are more valuable to you. But that doesn't mean you should assume things are simpler than they are.
The truth is that any job, has depth and far more complexity than appears at the surface. While in many jobs you can get away with only doing the simple part, there's still more depth than is actually being utilized. Likely for the same common error. You are right about cost being a big factor, but this is also a very different argument than the one about floor 8 and a half.
Again, you are making assumptions: I have read it in full, and I have experience with construction as well.
> someone may ask you to split a floor in half
Yes, I've seen it done plenty times. It's especially common with old houses which might have 4-5m high ceilings around here and people do introduce new floors in between.
Similarly, with pillars being carrying structures, it is feasible to go and turn 3 floors which are 4m high each into 4 floors ~3m high.
But while that's a way to interpret my "original ask" (and all of your examples like hidden floors and such), my intent was clear — in software, you literally go and introduce a whole new thing between the two things that were tighly coupled. Like actual structures above a certain floor.
If your implication was followed in software (i.e. try to predict the future and introduce hidden floors, service floors and such) — and it sometimes is — we really end up with worse, more complex software that has technical debt built in from the start. IOW, that's exactly not the way to build software.
Again, this does not discount the complexity of civil engineering — it is freaking hard! But my point is that it is DIFFERENT and that same approaches do not necessarily work.
> and I have experience with construction as well.
> If your implication was followed in software (i.e. try to predict the future and introduce hidden floors, service floors and such) — and it sometimes is — we really end up with worse, more complex software that has technical debt built in from the start.
Hillel discusses this right here[1] (this also addresses your last line)
>> The idea that software is inheriently unpredictable and you're always doing completely new things all the time. While engineering is basically doing the same thing over and over again. Umm... yeah... so... this is probably the only question I got where people would start laughing at me when I asked it.
>> And, of course, only someone who hasn't done serious engineering work in the physical world could say something like "The predictability of a true engineer’s world is an enviable thing. But ours is a world always in flux, where the laws of physics change weekly", thinking that the (relative) fixity of physical laws means that physical work is predictable. When I worked as a hardware engineer, a large fraction of the effort and complexity of my projects went into dealing with physical uncertainty and civil engineering is no different (if anything, the tools civil engineers have to deal with physical uncertainty on large scale projects are much worse, resulting in a larger degree of uncertainty and a reduced ability to prevent delays due to uncertainty).
In fact, let me quote from a footnote of Dan's. #2
>> When I listen to cocktail party discussions of why a construction project took so long and compare it to what civil engineers tell me caused the delay, the cocktail party discussion almost always exclusively discusses reasons that civil engineers tell me are incorrect. There are many reasons for delays and "unexpected geotechnical conditions" are a common one. ***Civil engineers are in a bind here since drilling cores is time consuming and expensive and people get mad when they see that the ground is dug up and no "real work" is happening (and likewise when preload is applied — "why aren't they working on the highway?"), which creates pressure on politicians which indirectly results in timelines that don't allow sufficient time to understand geotechnical conditions. This sometimes results in a geotechnical surprise during a project (typically phrased as "unforseen geotechnical conditions" in technical reports), which can result in major parts of a project having to switch to slower and more expensive techniques or, even worse, can necessitate a part of a project being redone, resulting in cost and schedule overruns.***
> my point is that it is DIFFERENT and that same approaches do not necessarily work.
I'll leave you with Hillel again[2]
>> people like Pete McBreen and Paul Graham who say that we are not engineers because engineering cannot apply to our domain. Engineers work on predictable projects with a lot of upfront planning and rigorous requirements. Software is dynamic, constantly changing, unpredictable.
[1] https://youtu.be/3018ABlET1Y?t=1085
[2] https://www.hillelwayne.com/post/are-we-really-engineers/
Obviously never been to floor 7 1/2[0]
It's great when you make a general statement about somebody you are conversing with without really knowing their background.
As Dan notes himself, even scenarios which are simpler than this (moving a bridge, moving a building) are done much more rarely compared to similar requests in software. I did not accidentally use "modify something in a dimension that's really hard to modify in civil engineering" as an example — perhaps your response was a cocktail party response of someone not understanding either civil or software engineering?
IMHO, it is all about costs (which I start off with being small in software — comparatively): traditional engineering doing changes like these is extremely expensive and thus they don't (it's usually cheaper to demolish and rebuild).