Something I missed above is that either prior, or concurrently, there will be performance experiments to check that things are staying sane, but these do not contribute to the later software development (except as a reference) and are likely not consistent with each other. The deliverable at this point is only documentation - getting it good as possible without any concern for impact on existing implementation. The goal is to get as far up the slippery pole as possible - inevitably things will slide back over future version iterations.
It is flawed for (otherwise) veterans too if they are trying to do something that they haven't done before so do not know what they do not know.
This really only works if you have done the same or something very very similar before and so you have practically no unknowns. Notice that the developer who did that commented above that they had already done similar work at the past.
Also related this quote about how Joe Armstrong (of Erlang fame) approached problems (from [0]):
> Joe wrote amazingly simple programs and he did so in a peculiar way. First he wrote down the program any old way just to get it out of his head. Then once it worked he would then immediately create a new directory program2 and write it again. He would repeat this process five or six times (program5, program6, ...) and each time he would understand the problem a little better and sense which parts of the program were essential enough to re-type. He thought this was the most natural thing in the world: of course you throw away the first few implementations, you didn't understand the problem when you wrote those!
