A while back I blogged about Jack Reeves' old code-is-design stuff and quoted Bob Martin as well. Well, it looks like Ted Neward found another somewhat similar quote from James Coplien in Multi-Paradigm Design for C++:

Many contemporary methods view design as a phase intermediate to architecture and coding, instead of viewing architecture and coding as products of design. But from a more practical point of view, we can't separate design fro either architecture or implementation. If design is the activity that gives structure to the solution, and if architecture is about structure, isn't "design" a good term for the activity that produces it? And much of the code is about structure as well. Why shouldn't that be "design" as well? If you look at how real programmers work, you'll find they really don't delineate architecture, design, and implementation in most application domains, regardless of whether the official house method says they should or not. (How many times have you completed the coding before holding the review for your design document?) Object-oriented designers gain insight into the allocation of responsibilities to classes by coding them up. Empirical research on the software design process reveals that most developers have at least partially coded solutions in hand at the time of their design review and thus design decisions continue into the last throes of coding [Cain+1996].