This discussion has been about what design is; if refactoring can
be considered to be design; if emergent design is still design; and
lately has touched the subject of metaphor vs architecture. My ADSL
line is down so I haven't read the postings from the last eight
hours, so forgive me if I repeat things that have been said.
Anyway, here are some early morning thoughts:


STARTING OFF

You always start programming based upon some initial decision. In
some cases, you're unsure about the design, or just don't want to
ignore your preconceptions for a while, so you start coding
everything in one class, or maybe even keep the code within the
test class to begin with.

Or, you feel more sure about the concepts and therefore start off
with a few classes in mind when you start writing the tests. The
point is, you can't start with an entirely blank canvas. If you
could, you would do the equivalent of closing your eyes, whisking
your brush on the palette to pick up some random paint and start
beating the brush on the canvas for a while, then opening your eyes
to see what you've accomplished. Then you'd study the painting to
see where the it wants to go and continue in that direction.

I listened to a taped Alan Watts talk once where he mentioned an
art competition in Chicago, where each of the contestants got a
block of plaster of Paris to make a sculpture out of. I don't
believe you can say that sculptors NEVER sketch in advance; I have
seen documentaries where the sculptors indeed made sketches and
small prototypes before starting on the real sculpture.

Anyway, the winner of this competition didn't make sketches.
Instead, she said to herself that the sculpture didn't want to be
anything, that it had no ambitions. So she started to demolish it
with by whacking it with a hammer, or something, until see could
see a direction it was heading. Then she continued from there.

In the same talk, Watts also spoke about sculptors "making rocks"
for Japanese gardens, where they try to make the rocks "more
natural" by following their grain.

My point is that you always start with something even though your
ambition is to try to get rid of your preconceptions. Sometimes you
start really simple, and at other times you start with a set of
classes just to see if it works and what ideas you get from writing
the code. Sometimes you get the ideas as soon as you start writing
the tests; sometimes it takes a little longer.


THE BEST WAY TO GET GOOD DESIGN

Whatever you do you're going to end up with a design. If you think
very little about the design, you most likely won't have as good a
design as if you think more about it. I feel that this attitude of
getting started by writing some code to see where it's heading is
very powerful, but there are people who want to spend some time
with a sheet of paper or at the whiteboard before coding. Which way
you choose should be determined by which you find to be the most
efficient for yourself.

Several years ago I saw a documentary about a photographer, and I
think it was Helmut Newton. Anyway, his style of working was to
arrange for the shot, set up the lights, and so on - and then just
taking one photograph (or a few) and he was done. My feeling is
that most photographers fire off ten rolls of film and then hope to
find something good when they study the negatives afterwards.

You could say that Helmut Newton is better at getting good results,
but that wouldn't be true. Another photographer might be excellent
in selecting the best negative to print. They're just different
styles.

So, you might do a little "design" in advance or you might just sit
down at the keyboard with your partner and start typing. Whatever
you call what you do, you'll end up with a design. The point is to
get it good and to find out the best way for you to make it good.

I myself really liked to draw diagrams and discuss the design along
with a few others by a whiteboard, but now I feel that I can
accomplish better things by thinking less in advance and by
"distributing" my thinking evenly over the time it takes to
implement something. I really like to be able to ignore parts of
the problem until later, when I know more about the possible
solution.


ARCHITECTURE

And since architecture and metaphor was mentioned, I'm of the
opinion that architecture is metaphorical; that architecture is
"metadesign"; that no matter what you do, just as you end up with a
design without thinking much about the design, you end up with an
architecture without thinking much about the architecture. I also
think that architecture exists at all levels, not just at "10,000
feet".

Architecture, in my opinion, is something that is "about" the
design. It isn't just the really high-level design. That's what is
meant by "metadesign". When you evolve your design you do that
according to your architecture - even if you aren't that aware of
what your architecture is. And if you're unsure about which of two
possible design solutions is better, your architecture can guide
you.

Let's say you're an architect about to design a house. You just
know that your task is to design a house at this time - not what
KIND of house. Then you're told that you're going to design a
skyscraper. BANG! You have a LOT of information in just that one
word. A skyscraper IS an architecture. It conveys a lot of
assumptions, such as that it is a very tall building, with lots of
elevators and a lobby downstairs. If you felt at a loss about the
design at first, knowing that the architecture chosen is
"skyscraper" really gets you going!

Now let's say you're a programmer about to develop an online store.
This is something very common in our time and the "shopping cart"
architecture immediately comes to mind. Knowing this, you probably
think of having classes like ShoppingCart, Item, Purchase,
Customer, etc.

And let's say that you were about to develop the software for
Amazon back in 1995, so you started off with ShoppingCart and Book,
instead. Then after a couple of months the Amazon people tells you
that they are about to start selling CD:s, and that they by 2002
are going to sell stuff like patio furniture and the diaper genie
(one of this decade's most talked-about baby items).

So, you sit down and think for a while and decide to extract change
the Book class for an Item class. This is evolving your design
according to your architecture (which is "shopping cart" in this
case). If extending the store involves creating a lot of classes,
and you also have chosen the architecture "three tier", that helps
you to break down the solution into classes. For example, you
wouldn't let ShoppingCart deal with HTML stuff, since the
ShoppingCart belongs to the middle tier and the HTML to the top
tier.

Also, the architecture conveys the bigger picture instead of just
individual parts with collaborations (the design). If you know that
the architecture is "three tier", you know more about where you can
expect to find things. Design patterns are also architecture, if
you allow architecture to exist at all levels. Knowing that the
pattern is MVC tells you a lot - as does knowing that Façade and
Observer are used a lot.


CONCLUSION

You can't have no design. You can't have no architecture. You can
either view it as you "do" design or as you "let it emerge" - and
the same goes for architecture. Design is "in your face" while
architecture more easily "stays in your unconcious" - as you make
decisions about the design, you automatically follow some
architecture or "metadesign". I think that you benefit from paying
attention to the architecture as well as to the design, and the
style that I find to work best is to think about it little by
little all the time, instead of in large portions mainly at the
beginning.

/P.

--
Peter Lindberg
Computer Programmer, Sweden
mailto:peter@...
http://tesugen.com