[samstave]

Well, look at tooling... and in the bridge analogy; material selection.

Look at the bay bridge, we built it using steel from china which, after it was already being used to construct the span was later found to be inferior.

So in SW dev -- you might choose a tool for a massive project only to find its the wrong/not best tool you could have selected based on the budget at the time the project started.

This can also be said of the team. Employee A was the right eemployee at the start of the project, but they later prove to not be the best resource, but youre already X% down the project timeline... what do? Esp at what cost.

[lzol]

I'm not arguing that that other forms of engineering are completely inflexible or that software doesn't have some constraints. I'm just saying that in general it is far, far easier to change lines of code than it is physical objects. That's why when there is a hardware issue that can be addressed in software, they send you a patch not a new CPU.

[samstave]

We are in agreement.

[C1sc0cat]

Or a surveying team missed some problems early on - and a bridge fell of its supports.

One Job I had (at a top 5 consulting engineer) was to reverse engineer the code from an onsite survey computer and build a GUI to analyse the data allow one of our Senior Engineers to look at what happened.