Willy's Reflections - Visual Studio ALM Rangers

| Willy-Peter Schaub | Visual Studio ALM Rangers | In search of IT simplicity, quality and tranquility |

Have I reached a design epiphany or am I finally lost in outer orbit?

Have I reached a design epiphany or am I finally lost in outer orbit?

Rate This
  • Comments 3

Pondering over design by synthesis versus differentiation.

Post revised on 2011/10/08

Context …

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

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

DSCN5963

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.

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

de_ws_01de_ws_02

Continued evolution will materialize the final snail drawing, that typically looks like the one below …

de_ws_03

… or even more evolved (refined) as the one my son Alexander drew for our community book “.NET Enterprise Solutions – Interoperability for the Connoisseur”.
Alex_snail

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:

Delightful!

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.

-Scott-

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.

  • Perfect, Thanks

  • I will, as usual, take a different perspective.  Your blog describes two differing approaches to design:

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

    Most design activities I am familiar with follow the Design by Differentiation approach. I am not aware of many *designs* that are developed using Design by Synthesis. Let me give you an example:

    When I was a teenager, I aspired to become a car designer in Detroit, Michigan. As a car designer, I was primarily interested in the shape of the car as a whole, and less interested in the engineering details such as the design of the engine or of the fuel system. I was fascinated when I saw designers create the shape of futuristic cars by carving them out of a block of clay. In fact this design activity was mostly one of subtraction – take a large block of clay and remove bits of clay by carving and smoothing until you achieve the shape you desire.

    Of course this does not result in the complete design of a working car. But it is a starting point. Once you decide on the shape of the *whole*, you can begin working on the design of the elements that will later be assembled to create the car on the assembly line. For example, you can design the contour of the seats, the dimensions of the wheels, or the size of the engine. But it makes no sense, in my view, to design the engine without knowing the context where that engine will be used. The context is taken from the shape of the *whole* car. Is this vehicle a sports car, sedan, SUV, or truck? How big is the engine compartment? These constraints, imposed by the design of the *whole* will impact or drive the design of almost all other components.

    Look at the works of architects Frank Gehry, I.M. Pei, Frank Lloyd Wright, or Antoni Gauid I am first attracted to the *shape of the whole* building rather than any particular feature. Certainly each of these architects had some fascinating details in their designs. But I suspect each of these architects started with the *shape of the whole* and filled in the details later. Rather than call this *Design by Differentiation*, I prefer to call it Design by Decomposition.

    This is, in fact, how I often approach the *Design* of software systems. I start with an overall perspective of the important features of a system and drill *down* into more and more levels of details. In fact, I don’t see the value of designing a detail of a system without understanding the context within which this detail will be applied.

    An important part of almost any automobile are the screws, nuts, and  bolts that will be used to fasten things together during the assembly process. Would you design a screw or nut and bolt without first understanding the context within which it will be used. How do you know how long a bolt should be, or what diameter a screw needs to be without understanding what it will be used to fasten together. Certainly you can look at screws, nuts, and bolts, as simple reusable components. Almost every home or assembly line has collections of these connectors. But would you select a screw or nut and bolt first and then figure out where it will be used. I think not.

    On the other hand, when you are building an automobile, or even a complex software system, you typically Construct by Synthesis. I prefer to use the term Construct by Composition. You start by assembling components from parts. You assemble these parts into larger parts (sub-assemblies). Eventually you assemble these largest components (seats, dashboard, engine, axles, body parts into the final product, and automobile.

    Even using your example of the snail, you already indicated your preference for Design by Differentiation. You started by visualizing the *whole* and added details such as eyes, helmet, etc. later.  Even your example, designing a snail by synthesis, really starts with a more holistic design. You would not design the snail’s helmet without already having a vision of how large the snail would be and how large the helmet needed to be to serve its proper protective purpose.  When you talk about using scissors to cut out the individual snail *components*, you are really talking about construction or assembly at this point, not design.

    Software design and construction is not all that different from the design and construction of automobiles or buildings, or almost anything for that matter. An important design principal is to reduce cost by maximizing reuse. Building object or software from reusable (or standard) components is a best practice.

    I am sure that at some point Frank Gehry uses standard, reusable components in his designs. But I don’t think he starts designing buildings by selecting from an array of standard windows or standard steel beams and then deriving the building’s design by synthesis. On the contrary, as he decomposes his designs and moves from the *shape of the whole* to the design of a window opening, he may adjust his design to take advantage of standard windows – or, in Frank Gehry’s case, maybe not.

    My perspective is that you almost always Design by Decomposition and Build (or Assemble) by Composition (or in your words Design by Differentiation and Build by Synthesis).

  • Well done   !!

Page 1 of 1 (3 items)
Leave a Comment
  • Please add 6 and 2 and type the answer here:
  • Post