How Buildings Learn

Last year at an internal Open Source conference, one of the invited guest speakers was Doc Searls. At one point in his talk, he mentioned the book How Building Learn and what a great read it was. At that time I thought that it must another of those inter-disciplinary "cross over" books, where the study of one field of work has influenced how things are done in another. For example, how the architectural book The Pattern Language has inspired and influenced the software book Design Patterns.

Because of this, I decided to buy the book last Christmas. I started reading it about three months ago, but it got shelfed for a while because other interesting things vied for my attention. I've been reading it a lot recently and I'm about half way through but as it looks like it's going to get shelfed for a few days while I dive into another book, I thought I'd post this now based on what I've read so far. There might be a followup when I finish the book.

Stewart Brand is an innovator. Amongst other things, he was the founder of the Whole Earth Catalog and The WELL. He's written some other very good books. For example, The Media Lab: Inventing the Future at MIT and The Clock of the Long Now. See a previous posting on mine on the subject of the latter.

How Buildings Learn is a very interesting book on how building change over time. If you read this, it will change the way that you think about buildings. The photographs help to make this book. They typically show the same building at different times during its history. You can clearly see how they've been modified to fit the current owners desires and needs. We've certainly found this to be true in the house we are in which we bought about two years ago. Since moving in, we've added a fence, replaced the garage roof, added air conditioning, put wood floors in in eight rooms and removing all the wallpaper that the previous owners loved so much, replacing it with paint.

One of the other things I really like about this book is that Brand doesn't toady. He says exactly what's on his mind, which is refreshing (his views on MIT Media Lab, and Fallingwater for example).

But there are some crossover ideas here, that we can (or already have) taken away and used in the software industry. Note that for brevity, I'm not fully defining what Brand gives for each concept, but just trying to give some equivalences.

• If buildings want to survive, they need to adapt to changes around them. Software is the same way. Always evolving to meet the needs of it's users. Examples: multiple specifications of languages such as C and FORTRAN. Additions to operating systems such as Windows and Unix.
• Brand talks about six shearing layers, Site, Structure, Skin, Services, Space, and Stuff to define how different parts and things associated with a building, change over time. For software, we regularily divide up different functionality into separate layers, so that it's easier to change them. Example: model, view, controller
• Buildings are
  • Low road - easy to modify and adapt
  • High road - high maintainence and hard to change
  • Magazine (no road) - famous or "art" buildings and monuments that shouldn't be changed

  Software could be broken down in a similar way, although I'm pressed to think of too many examples in the magazine category.

• The architects might have their ideas of what the buildings might look like, but by the time it's been built by engineers, it's probably nothing like what they originally envisaged.
• The simple straight forward design is the most functional. Reduce or eliminate the flashy features unless they're useful too.
• The best buildings are those designed and built by a single company that is responsible for all aspects of that building. If there is a problem, it's easy to get fixed because you know who is responsible.
• The concern that some architects, after designing their buildings, aren't interested in how they're built or any problems arising from that construction (that's the builders/engineers problem), or revisiting the project to see if anything useful can be learned. They are only interested in moving on to their next architectal design.
• "The longer that buildings are expected to last, the more you can expect maintenance and other running costs to overwhelm the initial capital costs of construction, and the more inclined owners will be to invest in better construction so they can spend less on maintenance".

That's just a few examples. I've only skimmed the surface of this book here. There's plenty more where they came from. Others will read into it differently I'm sure. There's probably a good paper that could be written on this crossover idea, or a doctorial thesis out there for somebody who wants to take it deeper.

This extraordinary book is well researched. It has lots of references and footnotes for each chapter and an excellent bibliography of further reading suggestions. I suggest you check it out for yourself.

[Technorati Tag: books]

( May 26 2005, 07:51:58 AM PDT ) [Listen] Permalink Comments [2]

Open Source Portability

[Original java.net posting]. Recently I've been trying to get various open source applications running on Solaris on x86 machines. These were mostly GNOME applications, but some of them were dependant upon underlying libraries that come from the Linux world. I've been having some trouble with some of these software distributions because the author(s) have only ever been concerned with GNOME and Linux.

I'm old enough to remember a time (15-20 years ago) when SunOS (the predecessor to Solaris) was the preferred Unix development environment and porting to other flavours of Unix was secondary. Linux is the main "Unix" development environment now. Fair enough, but developers should still think about what it would take to get their software working on other operating systems like Mac OS X, Windows and Solaris. It's not hard to abstract the differences out. It would give you the benefit of having a much larger potential user base too.

Differences come in two types here. Operating system calls and library API calls I group together. Then the second type is graphics calls. Let's talk about the system calls and library API's first.

Some people prefer huge #ifdef/#endif sections in their code to capture these O/S specific differences. My favorite approach is for your configure (or build) script to determine the type of platform you are running on, then compile a single different file depending upon that O/S type. That file would contain the O/S specific calls in a single place, each call in a separate routine with a common abstract name. The other files in the software distribution call these abstract routines and the build picks up and compiles the specific O/S file containing these routines and just does the right thing. It's clean, easy to understand and if your application has to be ported to several additional platforms at the same time, this can be done by multiple developers efficiently and in parallel without stepping on each others toes.

Handling graphics calls I believe should be done in a similar manner. Too many times I've seen an application written with just one graphical toolkit in mind. And with these graphics calls being done in all the source code files. Experience has shown me that a graphics toolkit has a life expectantcy of 5-8 years (some less than that). Then something better comes along. Or you need to port to another platform which doesn't support the original toolkit. Porting to another toolkit is then a nightmare.

I've been writing open source code for about 20 years now. Open source graphical code for multiple toolkits for about 17 years. The approach I've taken is to abstract all the graphics calls out into a single file that's specific to a particular toolkit. This contains routines with names like "draw_frame", "make_button". The routines in that single file then contain implementations of the required functionality using that toolkit API. Porting to another graphical toolkit is a simple case of creating another file with those abstract names in, and providing calls to the new toolkit within. Plus a little glue in your configure (or build) script to make sure that the correct one is compiled depending upon the platform you are running on.

Using this approach, I'm still able to use today a calcalator program that was originally written in 1987. It's seen numerous toolkits (SunView, X11, NeWS, XView, Motif, MGR, Gtk+ and even a curses version) and it's worked on numerous UNIX systems (plus a version that runs in an embedded system).

[Technorati Tag: software]

( May 26 2005, 06:32:28 AM PDT ) [Listen] Permalink Comments [1]