On the other hand, "slow is smooth, smooth is fast". Which strategy is optimal depends on the nature of the product and the cost of iteration.

In software, optimizing for speed works best in cases where architecture has minimal relevance for product outcomes. If I am writing a Python library then I typically iterate very quickly. Swapping out bits of implementation has low cost.

If I am writing a database kernel then designing any part of it poorly has a high chance of permanently crippling the implementation. Iterating is often tantamount to a major rewrite and extremely costly. You can only afford a very small number of rewrites before the iteration time stretches into years, so it is actually faster to spend much more time thinking through details that may seem unimportant.