[fluoridation]

Not to be that guy, but where can I read those interviews? I got as far as the blog (https://www.hillelwayne.com/) and looked around October of 2019 and can't seem to find anything. As it stands this isn't even anecdata, this is some guy saying some other guy said he talked to a few guys who say something happens from time to time.

[bryanrasmussen]

no idea but it stands to reason people will need to move bridges at times, we're in the middle of building a bridge, earthquake happens, stuff no longer like it was, gotta move that bridge is just the initial obvious situation that I can imagine from outside. Similar other natural disasters would also affect it, flash flooding etc.

[fluoridation]

I'll grant that, but that's not a "they don't do this as often as that, but", that's a "it's not unheard of". That was meant to be a response to a Tao of Programming-like post about why programming work has so much improvisation.

[godelski]

Well the reason you don't move a bridge is because it's really hard and really expensive. Just like you don't build an airplane while it's flying because it couldn't be flying if it wasn't built.

The analogies seem to just be missing the point. There's constraints, so what?

I've worked in hard science, engineering, and software. No one is omniscient, so the goals evolve and pivot during the project. That's pretty standard practice. You can't just plan and execute unless you're omniscient. Honestly, the big differences I see is that programmers spend less time at the drawing board and engineers and scientists spend much more time there because working in physical space is very costly and time consuming. But there's a lot of similarities. Programmers would be more effective if they spend more time at the drawing board and engineers would be more effective if they could hack on their tasks more cheaply (which is why sim has had such an impact for them)

[fluoridation]

>Programmers would be more effective if they spend more time at the drawing board

Would they, though? As you've correctly pointed out, design goals in software engineering get shifted by decision-makers because its cheaper than in civil engineering. The whole point of the ToP article is pointing out that software engineers have to account for possible future radical changes that in other branches of engineering are at most exceedingly rare. Any time you spend on initial planning beyond a bird's eye view may be time wasted.

[godelski]

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!

[fluoridation]

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.