Pondering over design by synthesis versus differentiation.
Post revised on 2011/10/08
Earlier this week I attended a 2-day “Design Patterns Explained” course, delivered by Scott Bain from NetObjectives. It was a phenomenal course and an exceptional presenter who loved anecdotes and visualization … bingo! The reason it took me this long to mention this course was that it was a brain-numbing experience, because the amount information was unbelievable … after day 1 my head felt like exploding and after day 2 an implosion was imminent.
But, this post is dedicated to a sub-section of the course, which has resulted in sleepless nights and more headaches.
We covered a section from the book “The Timeless Way of Building”, by Christopher Alexander. Note that this book was published in 1979 and is still relevant today … wow! Have you dusted off your DOS or Windows 3.1 reference books lately?
The section introduced design by synthesis and design by differentiation, whereby I am only going to quote two short snippets:
- Design by Synthesis … “Design is often thought of as a process of synthesis, a process of putting together things, a process of combination.”
- Design by Differentiation … “In short, each part is given its specific form by its existence in the context of the larger whole.”
Scott told us not to worry too much about these statements and quite a few others, which were as scary as the two extracts. “Wrong thing to say” to me, because I have now been pondering over the difference and why we typically start with Design by Synthesis, but should really Design by Differentiation for days and nights.
Last night, I believe, I had a moment.
Yes, when we ask developers who are passionate about the bits and bytes to build a system, we often drop to the smallest atom and we start writing snippets of code, designing when we get stuck and we continue to assemble bits and pieces like building a master piece using a box of LEGO pieces.
… Design by Synthesis?
My went when I walked past the shelves in my youngest son’s bedroom and pondered over the LEGO models which he built and inherited from his oldest brother.
… Detailed models which are unlikely to emerge from the box of raw LEGO
Surely the designers of these LEGO models did not start with the box of LEGO’s and started assembling. The most likely used diagrams, pictures and documentation from the much larger reference artefacts, then splits them (evolves) into parts that have a specific place according to its position in the real-world artefact.
Similarly the model aircraft, such as Alex;s favourite Euro Fighter, do not consist of pieces that were designed starting with atoms, but starting with the real-world aircraft and breaking it down into parts that again have a specific place (i.e wings) to its position in plane.
My final attempt to differentiate between the two design models will use the drawing of the infamous battle snail, which I created as my teams logo back in the Swiss army days when we lugged heavy equipment up the mountain, to drag it down the next day , to drag it back up the day after … while everyone was running, my team was less focused on speed, but more focused and successful with endurance and having fun at the same time … hence the snail.
If I were to design and draw the snail using Design by Synthesis, I would first design the atoms, the shell, the eyeball, the flower, the leaves, and so forth. At some point I would then use scissors, glue and other state-of-the-art design tools to assemble the snail by using the preformed parts.
… not very efficient and not very natural way of creating a drawing.
To Design by Differentiation, which is the natural way of drawing, I start with a “larger whole” the outline of the snail, which is evolved by adding detail, again according to its position of the whole, the snail. The shell goes in the centre, the helmet on its head and the eye is bet placed on its face.
Continued evolution will materialize the final snail drawing, that typically looks like the one below …
… or even more evolved (refined) as the one my son Alexander drew for our community book “.NET Enterprise Solutions – Interoperability for the Connoisseur”.
So why do we often design by synthesis, when design by differentiation is much more natural? That is assuming my analogy and understanding as outlined in this blog post is correct … and we all know what assumptions can result in.
Have I lost it? Have I had another of my many senior moments, has my head literally imploded or am I on the right track?
20111007 - I just got feedback from Scott himself and I quote:
Yes, I think you’re on the right track here, especially with the example of the drawing of your fighting snail. You start with the general shape, focusing on important “larger” elements and then adding details in finer and finer grains, wherein each level of granularity is influenced by the experience of the previous, larger context. It is a very good analogy.
I have often used the “Legos” analogy myself, actually. I compare, say, a bust of Socrates done in Legos to one done in clay, with the obvious distinctions between them. A thing built out of Legos, even when very well-done, is always clearly a thing made out of Legos. The same thing made from a plastic medium can look like anything.
Another way to say it is this:
- When building Socrates out of Legos, the nature of a Lego is part of the context you respond to while creating the bust.
- When building Socrates out of (any plastic medium), Socrates is the context you respond to while creating the bust.
Thanks so much for sharing that with me. Very interesting post.
In other words, I am on the right track and can enjoy the long-weekend in British Columbia! Cowabunga!
20111008 - WARNING: We had two lengthy comments vanish into a black home and are busy investigating. In the meantime please keep a copy of your comments and email them to me if you believe they are vanishing from the comments thread, so that I can add them to the post themselves.