You'll find 100s or 1000s of article espousing the opposite. That you can't know what you want until you try building it. You can't see all of the issues and all of the problems and how your design really doesn't work until you actually try to build it.
Imagine a chef trying to come up with a new dish. I suspect they don't write it down first. They mix things in and then see what to add to make it better. Sometimes they fail but don't think they'd get there by making cards. Cards are not the flavor and docs are not the actual product.
Maybe it fits certain products more than others or maybe like everything it just depends, some projects succeed using the waterfall style, others need to improvise.
Generally I think I prefer the iterate and edit style to the plan everything before you start style. But I also don't like wasting time so I'd prefer to spend as little time as possible going down paths that will be discarded. But often I think you can't know it's the wrong path until you get there.
"You can't see all of the issues and all of the problems and how your design really doesn't work until you actually try to build it." - assuming you build something, nobody has tried to build before.
In the 95% of other cases, use a library solutions, read about solutions that exist, try to learn from similar solutions. Don't reinvent the wheel.
It's not wrong to do experiments, learn from that and apply the know-how to production code.
> Imagine a chef trying to come up with a new dish. I suspect they don't write it down first.
Many chefs do. Especially when it's about the presentation on the plate, many chefs make a sketch first before they prepare the new dish for the first time.
Exactly! In my experience, a chef will do reasearch (they have a ton of notes/books/recipes), then combine some stuff and try things, but then will 100% write things down.
I think that's the key point being lost in any of these over-generalizations of "software" separated from actual industries and customer types.
Building a back-end system for a corporate client? Yeah, probably write a spec first and get them to sign off.
Starting an API-driven business, selling metered REST API resources? Definitely a strong case for writing the docs first, which are key to adoption and usage.
Building a new social, dating, or media network? Seems unlikely the docs are going to be a deciding factor in those projects' success.
Imagine a chef trying to come up with a new dish. I suspect they don't write it down first. They mix things in and then see what to add to make it better. Sometimes they fail but don't think they'd get there by making cards. Cards are not the flavor and docs are not the actual product.
Maybe it fits certain products more than others or maybe like everything it just depends, some projects succeed using the waterfall style, others need to improvise.
Generally I think I prefer the iterate and edit style to the plan everything before you start style. But I also don't like wasting time so I'd prefer to spend as little time as possible going down paths that will be discarded. But often I think you can't know it's the wrong path until you get there.