I feel like other engineering disciplines would function closer to the software world if it was easier to iterate. It is very difficult to nearly impossible to change the design of a bridge once construction has started.

If it was super easy, we'd very likely change things once they were in use. Perhaps we didn't account for pedestrians using the bridge and they're walking across it all the time or tractor trailers are having trouble making a right off the bridge. Software is inherently "soft". It's malleable. When done well, it can create better fit to purpose solutions than almost any other discipline. I agree that most "software engineering" is more like plumbing, but I do feel like "real" engineering disciplines would likely follow a similar paradigm if they had the same luxury to rework things.

The development of the road system as a whole is very much iterative.

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.

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.

We are in agreement.

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.

Agile is primarily geared for software. I believe it's in the first sentence of the manifesto.

So while your bridge scenario is correct, no one would do that midstream, software solutions often (but not always) can be flexible enough for change.

No, like all management fads, it just needed time to percolate. Now that software is so big, people who grew up in the agile domain have been promoted through the stacks to general engineering managers and have taken Agile with them. This means that folks in the hardware domain are now having to explain that you can't just keep iterating on ASIC's because it is really freakin expensive to make iterations.

It's the exact same trajectory that happened with Lean Six Sigma. It starts out as a good idea in a specific area. People start making money on managerial self help selling based on the idea. Market saturates. Product is pushed into other areas to keep growth. Engineering management idea becomes cult-like. New method comes onto scene and starts to displace the old.

Yes, but that isn't my point. The OP was griping about the difficulty business people have in seeing where the effort happens in software to produce something customer facing, and the dysfunction that happens from that inability to see it. He then wonders in a coda how big infrastructure projects ever succeeded with that kind of disconnect. I'm saying that a big factor at play is that agile subjugated the tech to the business in a way that large nuts and bolts engineering projects simply aren't allowed to do: requirements - down a fine level of detail - have to be provided up front. Once engineers in those domains have their requirements, they are really free to use their expertise as engineers. I don't mean to imply I'm a proponent of "waterfall", but it bugs me that agile evangelists think they've found The One True Way to do software, and don't acknowledge what I think are serious impediments to calling the act of writing software "engineering".

I see your gripe, and customers being promised demo's after every sprint is a bit over the top in many cases. Especially large projects.

But to assume no real engineering goes on discounts the fact that aside from stories there are "detailed" requirements, modeling, and designing that still occurs. If your team is skipping this, that's a problem.