The Dijkstra argument is that looking at examples, learning about concrete cases may prevent you from thinking about the most general abstract problem, for which you may devise an elegant solution. So according to the Dijkstra argument the prototypes you create may bias/prejudice your thinking, and should be avoided if you want to get to an elegant/optimal/general solution.
That sounds right, I can think of some revamp/rewrite projects that felt stunted because we only really thought about the problem in terms we already created in the first iterations.
However, in practice I find that programmers don't necessarily know what the (software engineering) problem is, what feasible solutions are out there (feasible != possible), don't know what the drawbacks to their plan are, and generally feel unmotivated if they don't start banging out code relatively soon. It seems really easy for a project to stay indefinitely in the planning stages if you want to make sure it's a "perfect" solution, and it's very hard to know that a solution is "perfect" without encountering its drawbacks through experimentation, i.e. coding.
