Notes on How Buildings Learn, Part 1: Anticipating Function

The word “building” contains the double reality. It means both “the action of the verb BUILD” and “that which is built” – both verb and noun, both the action and the result. Whereas “architecture” may strive to be permanent, a “building” is always building and rebuilding. The idea is crystalline, the fact fluid. Could the idea be revised to match the fact?
- Stewart Brand, How Buildings Learn, p. 2.

I hadn’t underlined the above paragraph, but as I sat down today with the intention to continue processing my margin notes, it caught my eye and I couldn’t resist the urge to quote it.

Like I said in my introduction, software architecture draws its inspiration from an illusion of what brick-and-mortar architecture is. The architect listens to the future user and draws plans, programmers turn those plans into code. The trend in development tools is to go directly from plans to code. Architected RAD.

The idea of software architecture needs to “be revised to match the fact” as well. There’s something about software that resists componentization. We have always wanted building blocks. Today, it’s services (as in service-oriented architectures, SOA); a couple of years ago it was, well, components, and before that, objects. The crystalline idea is to pick and choose among prefabricated building blocks and connect their sockets to match the boxes and arrows as indicated on the architectural plan.

Two quotes are most often cited as emblems of the way to understand how buildings and their use interact. The first, echoing the whole length of the 20th century, is ”Form ever follows function.” Written in 1896 by Louis Sullivan, the Chicago highrise designer, it was the founding idea of Modernist architecture. [His] form-follows-function mislead a century of architects into believing that they could really anticipate function.
- Ibid., p. 2-3.

If it is impossible to anticipate function regarding buildings, what says that we can do it for software? A part of me wants to say that it is possible to anticipate function for software, that it is different from buildings in this regard. Or perhaps the other way around: that software is function – after all, a building is just a container; the possibilities are less constrained. One thing that comes to my mind is that, here in Stockholm where I live, there are numerous supermarkets housed in former cinemas. Software is not like that: you usually just can’t start using a piece of software for a completely new purpose, unthought of when it was developed.

Software, being almost pure function, constrains its users, it dictates what can and cannot be done. Software architecture as it is usually practiced is about determining function, not anticipating. The architect studies the context trying to nail down which functions are needed. But determining function isn’t necessarily any easier than anticipating.

In almost every project, there’s an automatic requirement that programmers should document the code they write. Fans of agile methodologies sometimes criticize this because keeping documents up-to-date with fluid (yes, fluid!) code can impose significant overhead on progress. It is better, they say, to write clear code that communicates its purpose, and create diagrams showing the overall, less fluid structure. Perhaps with after-the-fact documentation of the code that emerged in the development process.

But a critique I haven’t seen is that the really tricky thing is to document the context – the reality in which the software is used. Documentation is perceived to have value as a device for explaining the system to new programmers, but the need to explain the context is usually overlooked – or perhaps it is seen as something best taught person to person. In my opinion, understanding of context must come first – and when one eventually understands the context, the code should be fairly understandable, and one should get by with an overall picture of the structure, and experienced programmers around to ask.

The very opposite concept [to Sullivan’s form-follows-function] is Winston Churchill’s ”We shape our buildings, and afterwards our buildings shape us.” These were clairvoyant insights, pointing in the right direction, but they stopped short. [...] First we shape our buildings, then they shape us, then we shape them again – ad infinitum. Function reforms form, perpetually.
- Ibid., p. 3.

Determining function is tricky because context is tricky. The only way to know for sure what works is building the software and exposing it to its intended context. So it is anticipation, after all. And because the context usually is very complex, anticipation is virtually impossible.

A particular context – say, a particular department in a particular company – is the product of co-evolution with its larger context. The people living in the context do lots of things they never think consciously of. New recruits are introduced not by reading documentation in ring binders, but by working and being taught person to person. The first time most contexts are described in detail is when custom software is to be developed. And capturing all the never-consciously-thought-of things is tricky.

Software needs to be introduced into a context as new recruits are introduced. By exposure with context.

The above was posted to my personal weblog on March 10, 2005. My name is Peter Lindberg and I am a thirtysomething software developer and dad living in Stockholm, Sweden. Here, you’ll find posts in English and Swedish about whatever happens to interest me for the moment.


Related posts:

Posted around the same time:

The seven most recent posts:

  1. Tesugen Replaced (October 7)
  2. My Year of MacBook Troubles (May 16)
  3. Tesugen Turns Five (March 21)
  4. Gustaf Nordenskiöld om keramik kontra kläddesign (December 10, 2006)
  5. Se till att ha två buffertar för oförutsedda utgifter (October 30, 2006)
  6. Bra tips för den som vill börja fondspara (October 7, 2006)
  7. Light-Hearted Parenting Tips (September 16, 2006)