Yeah. I find it weird to think not. Many problems are found during those planning stages. The process is iterative. Like I said, no one is omniscient. So that also means you can't just figure out everything during the planning stage. If that could be solved there then no one would ever pivot and frankly, that'd be a pretty strong case for planning in the first place lol.

But think about it this way, how do you plan a vacation? I'll tell you how I do it and you'll tell me if you're different, which is okay. There's no "right" or "wrong" way. I'm sure some things will be different and it's going to change every vacation, but bear with me here, since this is more of a communication aid than telling you how to vacation lol.

Prior to the vacation I plan out the major things, like how do I get there, how do I get back, the lodging, and so on. I'll have some key things planned out that I want to do. But I won't ever have everything planned out in detail. I actually do not like having each day scheduled unless that is more tentative and and acting as a stand in. Then after traveling my schedule changes, especially in the beginning. Things are different than I expected, so I'll learn that I'd have more fun doing X instead of Y. Or I find that I really like Z so I want to allocate more time to that. Maybe the weather changed and so I can't do P, and I instead do Q. I'll ask locals and hotel staff what their favorite places are to eat and go there. I'll likely have had a few more famous places to eat laid out, but definitely not every mean. Fuck, some days I'm just tired and would rather call the day early and do takeout. As the vacation closes, things become way more "stable". If I go to the same place in a second vacation I'll definitely lean on my experiences and do things very differently, usually with less flexibility (depending how much I was ale to discover what I like doing the first time around).

The point is that no matter what you're doing, there is exploration and exploration is coupled with the doing phase. It'd be pretty fucking exhausting to plan out the vacation at the airport. I mean people do do this and I'm sure you could still end up having a great time. But a little planning can really go a long way, right? That's the planning. Just like when you get back to your hotel at night and modify plans. That's a planning stage too. The logistics of a vacation almost force this kind of behavior on people. But in programming it is much easier to pivot, almost to the degree that you can be mid meal at a restaurant and decide you want to eat somewhere else. Being able to pivot like that is an incredibly powerful and useful feature, but this doesn't mean that planning still doesn't provide major benefits. Going in blind is crazy! If anything, it makes it more important. In both physical and software you still are time limited and unable to brute force all paths. In physical you can't jump mid meal and even if you pivot as soon as you get a good look, you're much more limited to what you can pivot to because you can't teleport across town. But in programming, you can. You can brute force sometimes, but that clock still ticks forward and you're still going to benefit from planning. The real difference is in physical I might be able to consider 2 dozen places to eat but in software I might be able to try a few hundred. Still need to plan if there's a few thousand, right?

You need to balance these things: the planning, exploration, and execution. Working in physical forces a dominating planning stage and more careful exploration stage, because execution is so costly. But in software execution is cheap. That doesn't mean we should throw out the planning stage, it means we can exploit it much more effectively!

I don't mean to be dismissive of the effort you went to in writing all that, but nothing you've said argues why software engineers would benefit from more planning. It argues for some planning, sure; I never said no planning whatsoever is good. If you intend to build, say, a website, that presents a very different set of challenges and usable tools than if you instead intended to build a microcontroller's firmware. But you seem to agree with me that in software you can turn on a dime, yet you don't don't offer any reason why more planning than what is already done would be beneficial.