You neglect something I think is very important: You do not normally know up front what code will live and not.
If you carefully (over-)engineer everything you will perhaps not get time to write all those short-lived failures that preceded that long-lasting success.
Of course I wish that piece of code that I hacked 3 years ago and never got around to refactor was better done the first time! But that kind of thinking ignores the fact that if my mentality had been "perfect up front" then what I would have spent all my time perfecting was the previous piece of code, the one I have long since deleted. I never would have gotten around to writing the hacky code I kept.
"You neglect something I think is very important: You do not normally know up front what code will live and not."
It's actually mentioned in my post and the whole point.
"If you carefully (over-)engineer everything you will perhaps not get time"
This is true. You can spend vast amounts of over-engineering instead of hacking something together that's "perfect up front." This is a false dilemma, though, as simply taking a little more time to think about or improve some code can work wonders. Better instead of perfect. You will still output less code but you'll have more useful and correct code.
I was answering to "using a substandard approach and language" -- if that is an option that's on the table I am assuming the time savings would be substantial (order of 50%). I do of course agree that one should often "Taking a little more time to think about or improve some code".
It seems like you almost say that it is better to be good at coding than bad at coding. Which I think nobody will ever disagree with. What I was talking about was assuming senior coders, knowing what they are doing, who think about actively choosing a shortcut.
I don't think it's a strict dichotomy, but I think there is a scale. For every project you can choose how well to do the job, and compare it to the importance the task seem to have and the budget it ought to have in developer time spent on it; then find relevant short-cut which does not dig you too much deeper in the hole. I usually try to figure out "how would I refactor this later to clean it up", make sure it can be done without too much pain, then if I can see the path clearly it's OK to take the shortcut if needed.
If you carefully (over-)engineer everything you will perhaps not get time to write all those short-lived failures that preceded that long-lasting success.
Of course I wish that piece of code that I hacked 3 years ago and never got around to refactor was better done the first time! But that kind of thinking ignores the fact that if my mentality had been "perfect up front" then what I would have spent all my time perfecting was the previous piece of code, the one I have long since deleted. I never would have gotten around to writing the hacky code I kept.