I mostly agree but dimensionality is also a huge one. Being constrained to 3 dimensions and standard building materials really limits the problem space. It's why you can probably figure out how to build a structure where all the entrances lock but you definitely shouldn't roll your own crypto.
No git, version control, copy paste.
You need to a bigger crane? Ouch.
Rainy season causes some delay? Welcome to the domino effect.
Supply chain issues? Oh well.. you better have good contracts.
Most applications are a 2D problem space: carthesian products.
I don't immediately see an analogy to supply chain issues but then I hadn't intended this as a pissing contest to begin with.
It's interesting to me that I'm getting defensive replies when all I pointed out was the increased dimensionality of the problem space when writing code versus assembling a physical product. I don't think that observation can realistically be contested.
I'm not clear what you mean by that. Most of the library code I deal with is far from ideal (IMO). Even most of the things I implement aren't ideal because either I'm interacting with the real world or even if not I don't want to spend unlimited time fully generalizing it.
As a concrete example, absolutely nothing that touches floating point arithmetic is "ideal" in any sense of the word.
That’s kind of hard with a foundation, or other materials
Yes.
I'm not sure this is a serious question, but the two have nothing at all in common. Anyone who says otherwise either has never welded or never used a computer.
One goes "commit to nothing, you can always change it later, hundreds of convenient tools at hand, move super quick but you don't 'finish' it, you just 'abandon' it".
The other is "commit early, make the best you can since changing anything is expensive, not too many tools, slap the roof and proclaim it good enough, ship it".
The difference is mostly due to destructive vs non-destructive workflows.
I'm not really saying one is better than the other, or even that the difficulty is different... but process-wise those things are miles apart.
Most programmers think too highly of themselves.
Software projects have the exact same problems as construction jobs, with the main difference liability.