[closewith]

Without fail, people who say this really mean "I am unable or unwilling to put in the hard work at the design stage to resolve uncertainty and will instead push these problems downstream to the development process where hopefully no-one will remember I'm responsible for the ensuing mess".

[anal_reactor]

Yes, that's correct. In other words, my cost-benefit analysis concluded that shipping fast and iterating later is a much better strategy than spending countless manhours on plans and meetings in order to provide a product that is perfect from technical perspective but misses both the timing and market needs. I don't understand this fetishation of "perfect code" when experience shows again and again that for most use cases, the correct approach is to ship fast and fix later. We're not sending a spaceship to Mars, we're making an AI-based social media app, either we ship this week or next week facebook will launch its own version which will make our product completely irrelevant and being first to release a feature is the only way to capture a statically significant part of the market. As long as the most common use case works we're grand, if 80% of the app doesn't work that's fine because 80% of the users only use the main 20% of the app, and the focus is on making sure that this works correctly.

[closewith]

> I don't understand this fetishation of "perfect code" when experience shows again and again that for most use cases, the correct approach is to ship fast and fix later.

You're conflating two separate issues, because design documents help you ship faster and fix later. They do this by making you think about what you're building, thereby allowing you and downstream consumers of the plan to focus on a smaller and more valuable set of goals.

Your approach is the opposite - building by gut feel and ignoring the available data. That's leads to wasted effort and elongated development cycles.

> my cost-benefit analysis

You don't plan, so you don't know your costs or benefits.