Design Of The Design

If the TheSourceCodeIsTheDesign, then what is normally called "the Design" really is one level more removed from the actual product than the design of a physical product. No wonder software design tends to be so abstract!

Shouldn't this shift in perspective have implications for our thinking about software design? Any thoughts?

--FalkBruegmann

Instead of TheSourceCodeIsTheDesign, we should say, "Designs should be executable". -- DaveHarris

I have always described a "Pattern" as the DesignOfTheDesign.

My reasoning is that a "Design" is the model that the source-code renders. Certain combinations of classes and methods appear so frequently that we begin to give them names, and think of them as entities -- I'm thinking of things like "Stack", "Queue", "RingBuffer?", and so on.

I call the collection of these things the "Design" of the code.

Certain combinations of these design elements appear so frequently that we begin to give *them* names, and think of *them* as entities -- I'm thinking of things like "Strategy", "Visitor", "Factory", and so on.

I call this DesignOfTheDesign the "pattern", in an Alexandrian sense. For me, this relationship seems to hold everything together and helps me keep the abtraction levels in order. Please recall that I assume that everything is expressable in a common reflective language, so all three elements can be described and manipulated within the same environment.

-- TomStambaugh