I'll ask you the reverse. What proof is there we absolutely need all this to function? If people are so sure of this, surely they can substantiate it with more than just rationality. If the similarities are fine, just pull that information from the other disciplines you insist know better than the "special snowflakes".

>Why does engineer or constructor worker understand that you need planning to align thousands of people over many years to build a great big thing

You're conflating "needing to align thousands of people" with "needing a fancy system which pulls everyone in its web to deal with multiple times a day". If anything, construction shows just how little ICs need to know to function. You don't boggle your construction workers with bureaucracy, you take it away and let architects, managers and foremen deal with it.

If you've worked in large construction, you'll realize just how many project managers large projects need to function.

There are an incredible amount of project managers running from place to place on a construction project keeping teams in line. Construction work, design blueprints, government regulator, there are SO many teams and SO many project managers running between them.

JIRA is absolutely a net positive in that environment. A centralized system like JIRA alleviates that.

You haven't addressed the part where the ICs have to be part of the system so thoroughly. You've only addressed that project managers need to communicate with one another and with their teams, and you've only done so by using anecdotal evidence, before drawing a conclusion that JIRA is a net positive.

Again, give some actual proof. It's about time we stop clashing rationalities and face the music. If it's this easy to come to a "rational conclusion", it shouldn't be much harder to pull evidence.

It is an issue in all fields. The reason why we have delays in major infrastructure projects and why software projects are notoriously hard to plan both boil down to unplanned and unexpected changes to requirements. The fact that it’s easy to change software makes it that much more vulnerable to last minute requirement changes. If something is exactly the same we can just reuse existing software and we don’t call that “development”. It simply becomes “buying” instead. And that makes most software development explorative in nature. Now tell me how many explorative real world, non-software projects have a well-adhered to and exact plan.

You're exactly right about software being exploratory, but I think the whole notion of fixed, up-front requirements is part of the problem.

In the lean analysis, the problem isn't changing requirements, which is a natural consequence of changing circumstances and people learning over time. The problem is building up a large inventory of poorly-tested, underinformed plans and then doing a lot of work based on them without taking advantage of the opportunities to learn.

Especially here on HN, we know that startups don't succeed because they come up with a fixed initial plan and then spend years marching to it. Instead we have all set of techniques for releasing early and often so we can see what really works for users. A key competitive advantage for startups is how their fast OODA loops allow them to run rings around larger companies that slowly drift into being very plan-based.

I was talking about software, not spaceships. Software, being soft, is fundamentally different.

However, you should watch the Poppendieck talk I linked. The Empire State Building had construction start before they finished designing it. The waterfall hallucination, where people imagine perfect results come from perfect plans perfectly executed, has been hugely enabled by software. But if we look at the actual results of heavily planned activities, like buildings, roads, and weapons development, the track record is terrible.

So if modern planning techniques don't work well even in areas, like construction, that they are most suited for, then it should be no surprise that people are skeptical when they are applied to domains that are very different, like software.