[allenu]

To me, it's really context-dependent and when working on a solution, you may need to take into account the business objectives and make the right trade-off in terms of time spent and "quality" of the design.

Architecture-level designs are important to get right as they can constrain your future self's ability to scale or adjust how the product works. However, it's also possible to spend way too long making a very open-ended architecture whose features you never actually use. (It may turn out you "build it to throw away" if you learn even more about the space you're working in as you go along.)

If you're working on a product and don't even know if it's something customers would use or want, I would say erring on velocity is more important than necessarily getting everything "right" in the design or even making the code beautiful. The thing that will most likely "go wrong" for you is that you built a product nobody wanted and not that the code just wasn't perfect enough. Better to get it in front of people sooner so you know if it's worth pursuing. Obviously, making that nuanced trade-off between "high quality" and "good enough" depends on your skill level and being able to recognize where things could blow up in your implementation if you do get it wrong.

Writing code is not done in a vacuum. We don't get to just write the most beautiful, optimal things with endless amounts of time. There are real business constraints and objectives we need to meet, and the trade-offs we make in terms of time spent should take the context into account. Unfortunately, most of are so separated from the real business objectives of the company leaders at the top, making it difficult to make the appropriate trade-offs (or even caring one way or the other). It often simply turns into "My boss wants this done in 2 weeks, but I would like to do it right and that will take at least a month."