This post originated from an RSS feed registered with Agile Buzz by Laurent Bossavit. Original Post: Design is intent - not Feed Title: Incipient(thoughts) Feed URL: http://bossavit.com/thoughts/index.rdf Feed Description: You're in a maze of twisty little decisions, all alike. You're in a maze of twisty little decisions, all different. Latest Agile Buzz Posts Latest Agile Buzz Posts by Laurent Bossavit Latest Posts From Incipient(thoughts)

Bob Martin started an interesting discussion back on comp.object, on one common rebuttal to the idea that "the source code is the design". The rebuttal runs along the lines of, "design is intent, whereas code is implementation". (This seems to be the same distinction as "what vs how".)

The etymologies of "intent" and "design" are fairly transparent; "intent" is from "intendere (arcum)", to aim as with a bow; "design" has as one of its roots "signare", to make a mark.

This suggests that designs are the visible traces of our intentions - code certainly fits that definition, but no more so than other things. (And design is not intent.)

If I go back to the image of "aiming an arrow", which underlies "intent", I observe that I'm always aiming an arrow at something. Once I fire the arrow, presumably what interests me is whether I hit whatever I was aiming at ?

Isn't that where "design" comes into play ? If I'm smart enough, I can come up with the idea of firing ahead of where I see my target rather than directly at it, so that the target catches up with my arrow. Taking the etymology quite literally, if I'm aiming at a moving target, I can draw a line in the sand at where my arrow is currently pointing, and prolong that line in my mind's eye.

That line in the sand is "design". It might have value, for instance in adjusting our aim for the next arrow. It might also have value in adjusting our aim before we fire the arrow - visualizing the arrow's path helps us decide that we won't in fact hit the target.

If I go back to programming with that thought, what I get is that the code is the design, and the UML is the design, and the scribbles on the back of envelopes are the design. Design is by-product. Some by-products we keep around, because they let us improve our aim.

What people mean by THE design seems to be something else. It seems to be something more permanent, more "essential" than a by-product. I don't see what that is, and in this discussion neither "intent" nor "design" seem to be casting any better light on what it is.

I suspect, but don't know for sure, that what matters is identifying the target (a.k.a. "requirements") and that what people mean by THE design - that permanent essence, which cannot possibly be the code - is an illusion, something they think must exist but actually doesn't.

I suspect, not that code is rather like design - but that designs are rather like code, a mere matter of implementation.