That works in mostly self-contained projects. As soon as you interface with other teams, or even hardware that is still in development, you better make sure that everyone is aligned on the critical details before plowing ahead. Otherwise it can get very expensive (in terms of time, money, and motivation) to prototype yourself into a corner.
Just this week I witnessed some team having built feature without consulting another critical team, and now it has to be reworked and shipped at a much later date.
> As soon as you interface with other teams, or even hardware that is still in development, you better make sure that everyone is aligned on the critical details before plowing ahead. Otherwise it can get very expensive (in terms of time, money, and motivation) to prototype yourself into a corner.
Even then, writing a prototype is often a quicker and more effective way to flush out disagreement than endless discussion.
But "endless" discussions or disagreements weren't implied at all. For a sufficiently large and complex project, where every participant (individual or entire teams) is only able to fully grasp a relatively small piece of it[1], there is sometimes just a lot of details to talk through, even if all participants are in full agreement and perfectly willing throughout that entire process.
To stay in the embedded world for an example, sometimes the actual code is just a few dozen lines with a handful of assembly instructions, or even less. But the danger and potential pain those lines of codes might incur on countless involved subsystems, if not properly thought out, even if seemingly "working" at first, can be immense.
[1] To give a sense of scale of complexity in the embedded world for example, the ARM Architecture Reference Manual alone is well over 10000 pages now. And that isn't any actual implementation, and only the "main CPU" itself!
Just this week I witnessed some team having built feature without consulting another critical team, and now it has to be reworked and shipped at a much later date.