A Pattern Language versus Design Patterns

I recently read a fascinating book by Christopher Alexander (and others) entitled A Pattern Language. I’d heard a lot about the book & had started reading it previously, but finally went out, bought a copy, and read the whole thing.

The idea underlying the book is that there are some things that make physical spaces “nice”. Some cities, some neighbourhoods, some houses, some rooms, some places in a room have some particular, maybe hard-to-pin-down, attributes that are universally enjoyed.

Alexander, an architect, embarked on a quest to find out how he could distill these attributes into something more systematic, something that could be repeatedly generated; not just by architects, but by normal people making their houses. The book is one attempt at this. It is, as he points out, A pattern language, not The pattern language – many sections in the book explain how this is just an example of how to implement this idea & gives guidelines on how one could make their own variants.

This will probably seem somewhat familiar to programmers, even down to the terminology, and for good reason: The concept of “design patterns” in software comes from Alexander’s musings. The listing & names of patterns are very similiar, the very structured ways the patterns are laid out in the books are similiar, the whole idea of trying to reify certain repeating patterns is obviously similiar.

There is one big difference that I’ve been thinking about though. Design Patterns is about making things easier for the software developer; it’s purely concerned with the ease of implementation. The user of the software doesn’t really enter into it.

A Pattern Language, however, is all about the “end user”. The patterns detail what is needed for humans to be comfortable in a space, how the artifacts can facilitate pro-social human interactions, how the things being built can make the world around them a better place. It only occasionally goes in to granular levels of implementation detail (mainly near the very end of the book) and even then, the granular detail is in service of ensuring that the things can be made in such a way that the end-user themselves can cheaply & sustainably build and modify the structure.

It makes me sad to think about how limited the thinking around software design is. Sure, there are things like Apple’s HIG (Human Interface Guidelines), but those are still narrowly technical and from a perspective that puts the programmer on an elevated tier, designing the world for the plebians that may be allowed in.

What would things look like if we could look at making software as more of a collaboration between the users & the implementers? If we could focus less on the implementation for our own sake and more on how the implementation can serve the user – or even by modified & extended by the user? There are some things that are like this, but vanishingly few, and even fewer attempts to make this a systematic process.

Granted, the complexity of writing software is extremely high. Sure, architecture has been around for a little bit longer than computers & has had more time for self-reflection. Still though, we can do better. Software needs philosophers and, apparently, architects as well.