← Back to context

Comment by necovek

15 days ago

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.

4 comments

necovek

Reply
godelski  15 days ago 

  > and I have experience with construction as well.

Just so we're clear, construction isn't engineering[0]. The difference does matter specifically in what we're talking about.

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

But again, I think this belies you. Yes, I've made the assumption that you either didn't read Dan's blog in full or listen to Hillel's video, but can you blame me? This sentence is something they both explicitly discuss. You don't have everything figured out in engineering. Frequently you are doing your designs and then get them built by a manufacturer and then reiterate. This is very much akin to writing code, running tests, and rebuilding.

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.

Or from Dan, not far in he says

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

I'm not interpreting your point too directly, I'm interpreting your point how you're asking I do in the followup. I am telling you the same problems happen in engineering. It is *all* about uncertainty. You are constantly doing new things that people haven't done before. In fact, the entire field of statistics is centered around uncertainty. Randomness is literally a measurement of uncertainty. Yes, it is true that in CS we don't have as formal of a base to derive complex equations and better (but not completely!) account for that uncertainty, but Dan also addresses this immediately after my quote.

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

(Emphasis my own.) Does that not sound extremely familiar? Rushing for the sake of rushing? That this rushing just incurs technical debt and more surprises? There's surely the constant of management wanting things to be done faster and not recognizing that this creates future trip-ups that create more anxiety to rush and just perpetuates the problems in the first place.

  > my point is that it is DIFFERENT and that same approaches do not necessarily work.

So I hope you can understand why I had thought you didn't read their arguments. I referenced the timestamp in Hillel's video[1] too. The next part of Hillel's discussion is literally about how much more predictable and consistent SOFTWARE is. *Their entire thesis* is addressing your point.

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.

[0] I must stress that I'm not trying to say one is more important or better, just that they are different.

[1] https://youtu.be/3018ABlET1Y?t=1085

[2] https://www.hillelwayne.com/post/are-we-really-engineers/

  • necovek  15 days ago

    You've missed my entire point which is still not addressed at all with any of the examples you mention.

    Please note that I never once claimed traditional engineering is predictable — you seem to be stressing a point out of your pre-conviction what a software engineer would believe and not what I am stating plainly.

    I am talking about a fully "finished" project (say, an apartment building, with people living in those apartments), needing to have a floor inserted in the middle.

    This is not about "changing requirements", this is about evolving a project that was initially built to be an apartment building into a stadium or an airport without messing up any of the apartment dwellers.

    Again, this does not mean that the agility and creativity actual engineering needs to posess is at all smaller (in fact, some of the examples that are hard with large physical structures, are trivial with software — like that "moving a bridge" example), but I stay unconvinced that the methods that work for engineering would work as well for software.

    As I believe most technical debt comes from attempting to predict the future and not rushing, I don't see the parallel there either.

    Basically, they are arguing points I didn't make and don't believe, and not addressing points I do make and do believe.

    • godelski  15 days ago 

        > I never once claimed traditional engineering is predictable

      I'm addressing this because you are stressing that software is unpredictable. You discuss this point as if it is unique to software. That is why I am pointing out that traditional engineering is highly unpredictable as well.

        > I am talking about a fully "finished" project

      I feel this is quite a narrow viewpoint and I'm not sure exactly how to address this. Do we consider a software project "fully finished"? I feel like you're pushing into a high level of specificity that extends outside the bounds of differentiating software engineering from traditional engineering and is more akin to differentiating software engineering from civil engineering and not from mechanical engineering. Civil engineering and mechanical engineering have different approaches, but their differences do not prevent them from being under the umbrella of "engineering". We're talking at that abstraction level. No one is attempting to claim that everything is similar between software and traditional, just as it'd be ludicrous to say that civil was the same as aerospace (try this with a bunch of aerospace folks, they'll get VERY upset). We're comparing forests, not trees. Yes, the trees make up the forest and they're different, but our discussions are about the similarities and differences in the forests.

        > this is about evolving a project

      Which is quite common in traditional engineering too. I've lost your point tbh. I quoted from both Dan and Hillel who address points in this direction. Are you being more specific? If so, would you elaborate? And does that level of precision even matter?

        > As I believe most technical debt comes from attempting to predict the future and not rushing

      While I agree that rushing isn't the only contribution to technical debt, and I even agree that over planning leads to debt, I think this is a mistake to say that rushing doesn't lead to debt. It should be clear at face value given that we all know that you don't know everything until you get into the code and working with it. Like you said, it is evolving. Meaning you learn as you're going. What's the saying? "Move fast and break things." It's a good motto but it needs an addendum: "clean up, everybody do their share." If you just blast forward to make things you're going to break things along the way. This is perfectly fine, as long as you don't leave a pile of garbage in your wake. That garbage is debt. Conversely you can spend way too much time planning and that too is debt, because as we've agreed, you don't actually know all the issues until you get your hands dirty. There's a balance here and if you're trying to put this on a binary spectrum rather than a continuum then you'll just create debt. There is no single contributing factor to technical debt, it is a multitude. A discussion of one factor is not a claim that there are no others.

      1 reply →