The Problem with Design and Implementation

The problem with implementation as design is that the implementation can be imperfect (underspecified, overspecified, or just plain broken) and thus can result in a difference between intent ("what you wanted to say") to reality ("what you actually said").

Then you get into the curious scenario where people trying to implement something whose design document is an implementation (e.g., the Ruby programming language, IE 7 "compatibility" mode) have to reproduce everything in the implementation, even the bugs, to be consistent with the design.

I very definitely write code as part of my design process. Code is free. It's not like building a shed where nailing some boards together to see how a truss should work costs money. Banging on some keys to see how sockets should interplay is free (disregarding time, but we're already engaged in "design", and I presume we are interested in "the right answer, sometime" instead of "the wrong answer, today"). So I code as part of my design process. I might throw that code away. I might keep a function or five. Who knows? But there is no way to know what the design is going to look like until you know all of the limitations, and the only way to know all of the limitations is to actually take a peek.