It is quite possible that the notion of emergent design is an anathema to architects.  Allowing a design to emerge from good practices is a bit like building a house by dragging wood to a homesite and deciding where the first wall should go.  It’s quite interesting and perhaps kind of artsy… until the first windstorm.

That said, a good many applications are built with the notion of allowing the design to emerge from frequent refactoring.  A lot can be said for “big up-front design” in terms of iterating a design on paper instead of in code.  On the other hand, it is easier to overdesign something if you aren’t actually writing the code, and the design doesn’t “appear” to offer a lot of value until the system is running.

Back in High School, I spent two years in drafting class.  Well, the first year was drafting.  The second year was labeled “architecture” but it was really a very light introduction to architecture.  We learned how to do home plans. 

I never forgot those lessons about careful planning and attention to detail.  We used patterns, although I don’t think my teacher had any idea that they were called patterns at the time.  It was just the “right way to do things.” 

In a way, these designs emerged.  From the point of my sharpened pencil scratching across the tip of a t-square on translucent vellum paper, I learned the value of a visual model, and how to erase a mistake without smudging everything up.  I learned to try things out, and accept that some designs were interesting, but not good enough to hand in.  For every design I showed my teacher, there were 15 sketches and five fully drawn main-floor plans that never made it past my drawing tube.

The designs emerged.  They grew out of my fascination with the environments in which people live, the spaces in which they eat and sleep and raise their children.  They grew out of standing in the central space of a busy shopping center, watching, waiting, hoping to catch a glimpse of why one shopping center had crowds, while another had communities.

I think, if I were to walk to a drawing board, tape up some vellum, and whip out a pencil after so many years, I’d make a huge mess… but I’d make a better house than I could have possibly drawn when I was sixteen.  You see, I’ve never stopped noticing those spaces.  I’ve never stopped looking for the quiet corner, the lovers nook, the family patio, the inviting kitchen.  I’ve been cataloging those patterns all these years, in my head, waiting patiently for some time when I’d need them.

And that is where emergent design has its place.  When it emerges from experience.  When you don’t start from dragging wood to a homesite and start nailing, but rather whe you whip out your vellum and draw, from the top of your head and the tip of your sharpened mechanical pencil, a design that is more mature, more excellent, more fit to the job than anything you could have done when you were still learning the craft.

Designs emerge… in the mind and imagination of every dreamer who refuses to grow up.

Refactoring is important, because nothing is “right” until it is understood, and nothing complex can be understood until it is done… but on the other hand, design, up front, is an expression of elegance and beauty that should not be foregone just because it is tough to do.  It is at that fine point, the point of intersection between experience and elegance, the point of a sharpened mind and a sharpened pencil, that architecture truly emerges.

By Nick Malik

Former CIO and present Strategic Architect, Nick Malik is a Seattle based business and technology advisor with over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

7 thoughts on “When emergent design doesn't”
  1. This is exactly why i don’t like "refactoring".

    To me, all this things about continuos refinement, sound like a child working with a pile of Lego bricks!

    Just my 2 cents..

  2. Well you’re nearly there. Mentally cataloguing patterns as you call them is only part of the design process.Over the years you must also learn to watch people and how they react to the environment in which they are placed…working, domesticity, or leisure. Then you must be up to speed on construction, materials, the individual site. There are so many factors that to design by a pattern will not work. Every building is a prototype. The only repetition that can occur is house design..yet who wants to live in a house exactly the same as their neighbour. There will always be an attempt to customise their property, why? Well to remain different, individual. I could go on but essentially my design tool is called Sectional Analysis. To give you an example, lets say I’m designing an art gallery… the reception area. First question, why is that needed, next what is it’s function, then how do I get into it, a door….why a door, what function does that perform…security, environmental, next Q, how do I open the door, what is it made of and why, door handle, how high, what material, cold, warm touch, soft hard all these components are the first impression of someone entering my art gallery. So you see, it’s the little stuff which leads all the way up to the big picture. An awareness of design questions is much more important the knowing the answers because the answers often change although the questions often remain the same.

    Comments welcome.


    Dave P – UK Architect

  3. Nick

    I got my first real look at the value of architecture while working with you, and later with Shawn.  I’m still trying to get my design feet under me.  I’m amazed at how far I have been able to get into my career without learning good design.  Probably because it’s a strategic skill, and not a tactical one.  It’s a skill I’m working on because of the reasons you mention.


    Somewhere along the road, "Refactor" has been co-opted by the non-Agile development world to be a synonym for "maintain", "modify" or "rewrite".  

    It’s definition is actually, "cleaning the code and design, without changing functionality" (Larman pg 149).  

    I liken it to "unfolding" your code.  Have you ever tried to see how many times you can fold a piece of paper?  The physical exercise of finding out, gives an interesting metaphor for software maintenance.  The first couple of folds are easy, the 6th fold is hard, the 7th fold is really difficult, and the 8th fold is going to require a vice.  The 9th fold is NEVER going to happen.

    Refactoring (if used properly, by someone trained in it) can remove a fold or two, allowing you to make that design change easy … or at least possible.

    Please take a gander at Craig Larman’s "Agile & Iterative Development; A Manager’s Guide" before you write off some valuable tools as childish toys.

  4. To Dave P (a pissed off architect… humorous).

    Dave: I haven’t been accused of being "nearly there" in well over a decade.  It would be flattering if it wasn’t condescending.

    You make a novice mistake yourself.  You assume that "your" analysis method is so unique that it deserves a name that only you know.  Your notion of Sectional Analysis is otherwise known as Functional Decomposition.  It is now largely defunct, not because it isn’t useful, but because, in the absense of real training, this nifty little technique leads to legions of developers all writing the same things over and over.  Each believes that their "door" or "entryway" is unique, and different, and no one elses can possibly fit.

    Working in a mature field, like architecture, teaches the value of templates, patterns, and reuse.  There are over 50,000 architects in the USA.  There are less than 200 who have ever designed a unique toilet.

    There are well over 100,000 professional software developers in the USA.  How many have designed a unique mechanism for validating that a field contains a formatted number?  (over half?)

    As an industry, we are infantile.  You suffer as do I.  Let’s learn together from mature industries that are not so naive as to assume that they SHOULD invent the plumbing every time they design a building.

  5. I’d like to respond to Chris Sterling’s post.  Didn’t feel like making another blog entry for it.  I’ll address to both Chris and Dave P.

    Gentlemen, if I appear to be saying ‘design is better than analysis,’ then please consider that I am not.  No one designs successfully without understanding the questions the CLIENT needs answered.

    What I am saying, however, is that design is a beautiful thing, and that it is difficult to do without experience and care.  Without putting down any other part of the process, design should be lifted up to its rightful place in software.

    Design is not about cataloging patterns.  Knowing patterns helps.  Knowing when to use them helps more.  Knowing why they work is more valuable still.  But design is more than this.

    Learning how to design does not mean learning not to listen to the customer.  The opposite is true.  Listening actively and deeply is necessary for the design to end up being more than a while elephant.

    While neither of you said these things, there were subtle implications that I felt the need to challenge.  

    My choice, in this post, to wax philosophic on the topic of design does not mean that I value design /above/ any of the other necessary skills and practices, especially not the gathering of requirements.  It simply means that design has a place in a world where BDUF is a dirty word.

Leave a Reply

Your email address will not be published. Required fields are marked *

seventeen − 11 =

This site uses Akismet to reduce spam. Learn how your comment data is processed.