Exploration Through Example

Example-driven development, Agile testing, context-driven testing, Agile programming, Ruby, and other things of interest to Brian Marick

191.8

⇒

167.2

⇒

186.2

183.6

184.0

183.2

184.6

Fri, 11 Apr 2003

But Syd: Design sequences

I haven't posted for the last two weeks because I've been head down coding. I find my English skills disappear when I'm compulsively coding. (That includes writing comprehensible comments, alas.)

However, this coding has led me to reflect on a couple of threads bouncing around. (I can still think while coding, though only in the shower.)

Andy and Dave have an interview that I'd describe as "appending 'But Syd' to YAGNI". YAGNI means "you aren't going to need it". To that, I characterize the PragGuys as saying "But Sometimes You Do".

Now, I've always seen YAGNI as a playing of the odds more than a Law of Nature. The bet is that you will - on balance - save time if you do only what's needed immediately. Sure, you lose time undoing work to add generality. But there's less of that time than the time you'd lose adding generality that turns out to be unneeded or wrong.

However...

There's this program of mine. I knew all along that I would add an OSX Cocoa GUI. And I suspected I'd want an HTML interface too. But I didn't know Cocoa, and I wanted the program working for my own use, so I started with a command-line interface. (I live in Emacs anyway, so having the program be only an F8 away is convenient - better than a GUI, really.) As for laying down infrastructure for the other two interfaces... YAGNI.

Time has passed, and I fer sure need those two interfaces, because Bret and I will be giving a tutorial on Scripting for Testers in May. (In part, this advances our campaign to make Ruby be the tester's favorite language.) Students are going to test my program through the command line (which is the Ruby interpreter), the browser interface, and a "web services" interface (Distributed Ruby). And I have to be able to show them the GUI.

So my development sequence was this:

• lots of command-line commands.
• a rather shoddy GUI, but good enough for our course.
• an HTML interface.

But I could have pursued an alternate sequence:

• add one new command to the command line.
• add it to the GUI.
• add it to the browser interface.
• iterate until those commands have made me write a solid infrastructure.
• add the rest of the command-line commands so that I have a tool I can use.
• add those commands to the other interfaces.

I believe that the second sequence would have led to my being farther along today and would not have delayed the first 'release' by much. I also have a hunch that the design would have been cleaner.

What does my experience have to do with Dave and Andy's article? Christopher Alexander (the architect who gave us software folk the word "patterns") talks about "design sequences". Here's what Ron Goldman had to say about them in a posting to the patterns-discussion mailing list (patterns-discussion-request@cs.uiuc.edu):

In "The Timeless Way of Building", "A Pattern Language" and his other writings, Christopher Alexander describes how patterns are organized into pattern languages, and how one must apply the patterns in a specific sequence to create a beautiful and whole design. He stresses this in his latest work "The Nature of Order" and on his web site (c.f. http://www.patternlanguage.com/sequencetheory/sequenceopener.htm).

When creating a new building, a sequence presents a series of design questions in a very specific order. As Alexander writes in TTWOB: "For once you find the proper sequence, the power to design coherent things follows from it almost automatically, and you will be able to make a beautiful and whole design without any trouble.... But, if the sequence is not correctly formed---if the sequence is itself incoherent, or the patterns in it are incomplete---then no amount of trying will allow you to create a design which is whole." [pg 382]

As a crude example, consider how important it is when building a house to first decide where on the site to build it. Only then can one make intelligent decisions about the house itself. Note that this is not just an example of top-down design --- though it does include elements of that --- but more about the order to tackle design questions that are at the same level.

Does This Apply to Software?

From Alexander's many years of experience he knows that sequences make sense for building houses, but what about for software? For example, in the old procedural programming world the general advice was to first design the data structures and only afterwards start writing code --- but that's pretty generic. How specific can we get?

My question is to those folks on this list that have developed many different implementations of similar software: Do you have a specific order to how you design it? If you're building another e-commerce site do you generally build it the same way each time? When building an embedded system is there a design question you always tackle first? Are there design questions that you know have immense ramifications, so you need to deal with them first?

My hunch is that Andy and Dave have experience that's led them to internalize particular useful design sequences for particular types of software. So they know when it makes sense to start by using metadata, and they don't need to wait for change requests to push them toward that conclusion. Such experience, in the hands of proven craftsmen, trumps the business-value-first approach that makes sense when you don't have proven sequences.

Unfortunately, Ron's discussion petered out, but I'd like to see it get restarted somewhere, because I think there's something there.

I'd also like to see a workshop somewhen that starts with a fairly fixed set of requirements, then has different teams implement them in different orders, then gets everyone together to reflect on how the different "trajectories" influenced the final product.

I'd also like to speculate on the interplay between Alexander's notion, where sequences seem to be a property of experts, and Dave's recent posting on karate, where things-like-sequences are more the province of novices. However, I've run out of steam for this posting.

## Posted at 07:05 in category /agile [permalink] [top]