In the world of software, I think this counterpoint definitely applies. When faced with a new problem, especially when greenfielding, I sometimes have the impulse to just jump in and start writing code. Almost every time that I succumb to that impulse for a complex problem, I discover weird edge cases and lots of little issues which could have been avoided by further contemplation at the drawing board. Stated in a similar format: a lot of refactoring can be prevented by a few extra hours at the whiteboard.

I've also seen people do a ton of up front design, only for things to fall apart quickly during the implementation. I'm still largely a proponent of writing code sooner rather than later. Iterative development. Prove out concepts in isolation along the way. Rewrite and integrate as appropriate. But obviously you've got to do some upfront work, otherwise you might write custom software for things which have off the shelf solutions.

I find that as long as you start with the DB schema and core interfaces (system level rather than code level) and then move to framing out the general pillars of the code that you often will get 80-90% right. Refactoring will be a plenty but that is true in every project no matter the upfront planning. Just don't miss any edge cases which rewire your schema and you generally can keep a good pace on forward progress. Also it's generally true that the larger (see more complicated) the problem the more planning one should generally do.

The challenge is that it's often not possible to understand which few extra hours at the whiteboard will save you the refactoring, or even which code will be worth keeping around long enough to be worth refactoring.

I've experienced both of these extremes - days of refactoring that could've been avoided by a few extra hours thinking about the problem, and days of refactoring that could've been avoided entirely by shipping the product early and realizing it was a bad idea to begin with. I think the optimal approach is actually to sketch out a simple solution first, ship it with bugs and all to a group of small trusted testers (or even just use it yourself), and then reevaluate which parts of the product are actually useful. Then throw out the 80% that's of marginal utility and really think through how to implement the remaining 20% in a solid way that you can build upon. Repeat once you have that launched, building out additional features in the same way.

"Weeks of coding can save hours of design"

Months? Bah. Try years.

>months in the lab saves hours in the library

It's possible to outperform other laboratories by accomplishing both regardless.

Working harder AND smarter has its unforseen advantages.

Rich Hickey's phrase for this is "hammock driven development".