Refactoring, design, architecture (Irrational Software)

(This is something I wrote on the testdrivendevelopment mailing list, as part of a discussion on refactoring, design and architecture. See here for the original post in context.)

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 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.