When emergent design doesn't

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.

Comments

• Anonymous
  March 06, 2006
  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..
  
• Anonymous
  March 07, 2006
  The comment has been removed
• Anonymous
  March 10, 2006
  I think you might be interested in my concept of Prefactoring - a series of guidelines based on experience.  
• Anonymous
  March 12, 2006
  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.
  
  
  
  Luciano
  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.
  
• Anonymous
  March 18, 2006
  The comment has been removed
• Anonymous
  March 23, 2006
  I posted a review of this blog entry at <a href="http://jroller.com/page/csterwa/20060323">http://jroller.com/page/csterwa/20060323</a>.
• Anonymous
  March 27, 2006
  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.