I’ve recently read Scott Berkun‘s excellent book ‘A Year Without Pants‘, where he reports from his experiment of working for Automattic (the wonderful guys behind WordPress). He was tasked with the introduction of team structures into the perceived chaos of an entrepreneurial, DIY-minded and bazaar-like organisational culture.

The book is remarkable on various accounts:

• It is a wonderful anthropology of the practice of remote working and how Automatticians make it work;
• It treats organisations and the complexity of organisational culture with due respect, subtlety and nuance;
• It asks the right kind of questions that we should all ask ourselves: is the work we do meaningful? How could we make it more meaningful? How could we empower people to do the things they enjoy and want to be doing? Is work making us happy? If not, what could we change? As such, the book is an inspiring manifesto for the future of work.
• It is funny and generally a good read.

But what striked me most were the descriptions of how the work of coding, programming and designing software works. I’ve long been fascinated with this topic and Berkun provides lots of insights on this (another – way more academic – book that touches on the subject by the way is ‘Code/Space. Software and Everyday Life‘ by Kitchin and Dodge).

Berkun himself provides plenty of analogies between software and physical spaces. For instance in chapter 2, he compares the chatting protocol IRC to the corridor in a building:

“IRC was like the company’s hallway. While Skype was more for one-on-one communication, IRC was where you went to talk to large groups, find help, or seek out people who wanted to socialize. And since there are people working from nearly every time zone in the world, there was always someone online to help with a problem or joke around with when you’re working.”

I found this thought fascinating – is software like a building? And is designing software like designing a building? So could architects and designers learn from the software community?

Let’s start with the commonalities between designing software and buildings:

1. Software and buildings both create spaces – digital spaces in the case of software and physical spaces in the case of buildings.
2. Spaces create affordances for people’s behaviour. Or in the words of Berkun: “Technology does have an impact on behaviour”. The same could be said about physical spaces: they have an impact on behaviour, as shown in a lot of my research (see a full list of my publications as well).
3. Berkun then continues with his quote: “Technology does have an impact on behavior, but culture comes first.” Again, the same could be said about physical spaces. They tend to shape behaviours, often in a probabilistic way, but culture can always override spatial factors.
4. Spaces create an interface that allow people to connect with one another – either digitally or in face-to-face encounters.

However, the most obvious difference between software and buildings is the lifetime of the spaces they create: software is normally released every few months (and in the case of Automattic and WordPress digital spaces are changed even daily or weekly). In contrast, buildings last. And last. For decades and sometimes centuries. Stewart Brand has categorised the different timescales for changes in the construction industry in his fantastic book ‘How Buildings Learn‘ and came up with the following six “S”: Site (eternal), Structure (30-300 years), Skin (20ish years), Services (7-15 years), Space plan (3-30 years), Stuff (furniture, i.e. it depends).[By the way, here’s a great summary of the book] What matters most for the creation of an interface between people is another “S”: spatial configuration. Since it combines structure with the space plan, we’re in the ranges of decades (if not centuries!) regarding the longevity of changes.

This means it is inherently difficult to adapt and change physical spaces and once you do change them, the expectation is that this refurbishment will again last for at least decades. What a responsibility for the architects and all the other engineers and professionals involved! And given all of the constraints (site, politics), limitations (budget) and uncertainties (does the client understand what they want?), it is also a complex task. You might now think that with this huge responsibility and complexity comes a particularly rigorous and thorough process of ensuring that the final product is the absolute best it could possibly be – involving the careful establishment of specifications and users’ needs, finding the appropriate design model, testing for stability and functionality, eradicating ‘bugs’ and as soon as it is in-use, collecting data about those very patterns of usage in order to improve. That’s at least what high-quality and high-risk software designers would do (and of course not every software process works that well…). Most architects in contrast (and of course there are exceptions…) go down the complete opposite route and rely on their intuition and experience. They tend to hide from the mess, complexity and contigency of the real world, as argued powerfully by Jeremy Till in his book ‘Architecture Depends’ and instead prefer to pursue perfection. Scott Berkun notes the same phenomena in chapter 12 of ‘Year Without Pants’:

“Architects are notorious for designing and disappearing, never returning to see how their choices worked or failed after the building opens.”

Arguably, it is easier to learn from usage patterns, if they fall into your hands automatically; and arguably, it is easier to create products that can be adapted swiftly and in quick successions of test-apply-evaluate cycles, where the stakes are considerably lower, so in some sense the comparison between software developers and architects is not very fair. Still, I think there are interesting lessons to be learnt for architects from their design colleagues in software development.

My colleagues at Spacelab – can you tell they’re designing buildings and not software?

So here’s my wishlist for building designers, inspired by Scott Berkun’s description of work at WordPress:

• Build lasting customer relationships and aim to understand your customer’s needs. Often clients themselves cannot properly articulate their needs, but this is crucial. The construction industry shouldn’t be getting away with being considered ignorant (‘designing and disappearing’) and instead learn from other industries, specifically service industries.
• Focus on the interface that the building creates. The interface, or the way a building orchestrates the flows of people and brings them together or keeps them apart is one of the most important aspects of a spatial structure. Too often it appears that buildings are seen as sculptures or facades (at least that’s what high-gloss architectural magazines make us believe) and seem to ignore how they will be used. Berkun sees a similar mistake happen in software design: “The natural mistake engineers make is to build from the bottom up. They leave the user interface last, assuming it is the least complex technology. This is wrong. Humans are much more complex than software, and since the interface has to interact with people, it’s the most difficult to do well. By building from the bottom up, technologists paint themselves into a corner, resulting in ugly, hard-to-use things. By the time they finally got to the user interface work, so many constraints exist that even the best designers in the world couldn’t salvage the project. The answer is simple: design the user interface first. This is a mandate at any organization that makes things people love to use.” (Chapter 19).
• Collect data of usage patterns wherever you can. This does not limit the architect’s creativity nor does it release the architect from taking decisions. That’s how Berkun described the relationship between data and decisions: “Data can’t decide things for you. It can help you see things more clearly if captured carefully, but that’s not the same as deciding.” (Chapter 10) Data on space usage is still rare and we need a lot more of this type of systematic inquiry and understanding, if we want to design better buildings.
• Develop intelligence and collect the right type of data. Berkun argues that a good process will “consider what data will tell you it works”. This will vary from context to context and possibly from project to project.

So is designing software like designing a building? The answer is: not really. But maybe it should be. At least a little bit more.