The more important things for me in What Is Software Design?:
1) The high level structural design is not a complete software design; it is just a structural framework for the detailed design. We have very limited capabilities for rigorously validating a high level design so coding, Testing and debugging are design validation

2) Because high level structural design is just an small definition of software design it is probably better to let the original designers write the original code (refine their design), rather than have someone else coding with only the high level structural design as guide

By the way you miss the last l in the link
http://www.developerdotstar.com/mag/articles/reeves_design.html

@Jeremy – I’ll tackle your points in reverse order. Regarding tests, Jack is saying that the action of testing is part of the design process. He is not saying that the tests themselves are part of the design. (I have heard some argue that automated unit tests can help with understanding the code, so it that sense they might function as part of the design documentation.)

Your other points all seem to assume that the code is an implementation or instantiation of a separate design. I agree the customer may need to see a high-level design document. But what Jack and I are saying that the code _is_ the detailed design specification. You could perhaps say that the code (as detailed design) implements the high-level design, and both levels of design need to fulfill the customer’s requirements. But I don’t agree that saying this implies there can’t be defects.

@Quick Comment – I’d agree if you said code is too low level to convey high-level design or architecture instead of just design. I didn’t mention it in my article, but in the appendix of the book Jack provided some additional follow-up remarks, one of which discussed the importance of architecture documentation. You are not the only one who seems to assume that Jack or myself is saying that separate design documentation is not needed. I’m not sure why people are coming to this conclusion, but this is not the point we are trying to make.

Huge difference, especially if it was a conceptual diagram.

What if we could take the design just as another coding phase? In fact, if we take the whole process of software develoment this must be so. Requirements, design, coding… are just translations of the ideas into successive forms of “code”.

Requirement gathering is a form of coding, with a syntax quite strict a lot of times. You codify the needs of the client into tables, bullet points or whatever.

Design translates that into another code, one which organizes those tables, bulletpoints or whatever into stories, use cases, etc. The language used can also be somewhat strict and it’s certainly not natural language. The design document is coded into “developer language”, a form of code “compiled” to “run” in the developer head. S/He then translates it into another code, the so called source code.

So The Design is Source Code too.

Upon reflection, perhaps the title of the book’s appendix and my article is not the most accurate portrayal of Jack’s article, but I think it is fairly close. Note that I quote Jack as saying that up-front design is still important (”we desperately need good design at all levels.”)

“The Source Code Is the Design” is an XP concept. Jim Coplien, among others, has argued that more up-front design than just the code itself is appropriate in an agile approach.