Monthly Archives: March 2013

Pace layering

Another one of those observations that just rings true on so many levels is that a single system has components that change at different rates. It was identified by Stewart Brand in his book How Buildings Learn

The concept of pace layering (Brand 1994, Morville 2005) sees a building as a series of layers that have differing life spans. The site itself has an eternal life, whereas the building structure might last 50 to 100 years. Other layers such as the external cladding of the building or the interior walls might have a life of 20 years with internal design, decoration and furniture lasting for 5 to 10 years. In a rapidly moving world it makes sense to locate the capacity for change in those items with the potential shortest life span and avoid, if possible, creating some layers, such as internal dividing walls, that have a medium term life span and are a potential barrier to accommodating changing activities.

Taken from JISC, via Tom Graves’s post.

In architectures of any kind—software, enterprise,or physical—failure to accommodate for this will ultimately tear your system apart. In any case, accommodating different rates of change, as in gears in a machine operating at different speeds, requires careful design of the interfacing points. Another reason that designing good and enduring interfaces is hard.

Small steps

In a classic example of what goes wrong in bigger environments, I wanted to knock up a quick tool to solve a problem. I decided to use Clojure because the solution involves data transformation from XML to JSON, so a functional approach makes sense. I also want to improve my Clojure skills, which are on the amateur side.

Leiningen is the natural lifecycle tool. I created my project, updated my dependencies in project.clj to the latest version of the midje testing tool, and in fine TDD style wrote a quick sanity test, ran lein midje and got a green response. Good work.

After some reading up on XML zippers in Clojure, I then made the timeless error of overconfidence by taking a big leap forward and writing a simple functional test that required a number of implementation steps, including coding and updating components and tools. Pretty soon, I was in Leiningen hell, getting meaningless exception stack traces, thrashing around trying different versions of tools and libraries, and commenting out increasingly large pieces of code until I found my issue—in about the second line I’d written. Lots of time wasted, no value delivered.

Moral to the story: when you’re in unfamiliar territory, you move faster if you take small steps.