It really doesn't, unless you've already implemented a variation of the thing before.
There is a time for reflection and planning/thinking about a given software problem, but you're mostly wasting time doing so in-depth before you've done/looked through a rudimentary implementation.
Your planned architecture will be worse then the one from the person that interated several times while introspecting the resulting code, discovering misconceptions on the way.
Do note that this initial implementation is only there to learn the domain of the software, basically.
The phase can be skipped if you're not really changing anything and mostly just reimplement something you've done before. At that point, you're not doing something new however.
> initial implementation is only there to learn the domain
I've been trying to do a kind of documentation-driven development, where I write a fairly detailed README file before I write a single line of code. It hasn't gone as smoothly as I imagined, I think it takes practice to get more effective - similar to test-driven dev. And it made me realize my usual approach is "to think by coding", and to explore the problem space with a rough draft of a program.
It must be a common approach, as I've heard people say "Throw away the first draft." Not only in programming but about writing in general. Ah, there's even a term for it:
There is a time for reflection and planning/thinking about a given software problem, but you're mostly wasting time doing so in-depth before you've done/looked through a rudimentary implementation.
Your planned architecture will be worse then the one from the person that interated several times while introspecting the resulting code, discovering misconceptions on the way.
Do note that this initial implementation is only there to learn the domain of the software, basically.
The phase can be skipped if you're not really changing anything and mostly just reimplement something you've done before. At that point, you're not doing something new however.