Comment by necovek

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