And it's a terrible way to make anything, much less software. It's more forgivable when the cost of outer iteration is high because you're making, say, a train, but even then you design around various levels of simulation, iterating in the virtual world. The idea that you can nail down all the requirements and interfaces before you even begin is why so many projects of the type you describe often have huge cost overruns as reality highlights all the changes that need to be made.

I see this so often. It's how terrible software is written because people are afraid to change direction or learn anything new mid project.

I rewrite most of my code 2-3 times before I'm done and I'm still 5x faster than anyone else, and significantly higher quality and maintainability as well. People spend twice as long writing the ugliest, hackiest code as they would have to just learn to do it right

So you think it is smarter to, say, tell the carpenters “just start building a house” without giving them plans?

What you described is not how successful products are built and maintained; what you described is why we have world full of lots of shitty tech from “move fast and break things” ADHD-like management and young programmers that think they know everything and cry about having to do thinky work first. Literally the worst kind of programmers to have on a project.

I'm talking about engineering, not manufacturing. I'm not suggesting not thinking, I'm saying that you cannot design every aspect of a system without learning more about the design. It's just a restatement of "Gall's law" (in scare quotes because it's obviously not an actual law). Alternatively it's the obvious way of working given the principles espoused in the agile manifesto.

Your absolutism is at odds with reality. Engineering and manufacturing are literally joined at the hip, and both require a significant amount of planning. If you disagree with this, well, good luck with your engineering career, is all I can say!

Precisely! The idea that you can set down the requirements and all the design decisions before you even start thinking about the implementation is completely flawed.

The engineering/manufacturing dichotomy was just with respect to your statement about carpenters. Even then, expediency on the part of the manufacturer will often result in design changes.

> companies that take programming seriously (e.g., banks, governments, automotive, medical equipment, etc.)

(Some) banks (sometimes) hire armies of juniors from Accenture. I wouldn't say they take programming seriously.

My government had some very botched attempts at creating computer systems. They're doing better these days, creating relatively simple systems. But I wouldn't say they're particularly excellent at programming.

Somewhere in that list you need to add some time for certification, plus rework after certification failure!

Not only does it take a week, but each attempt costs a few tens of thousands of dollars.