Shaping with pattern languages

I'm re-reading Battle by Christopher Alexander. It shows the exact steps he took to design and build the Eishin Campus in Japan.

I feel like a student in a master class when I'm reading this. The phases he went through map very well to Shape Up concepts, but his methods are worked out more precisely, more robustly, and seem more mature.

For example, we can say the shaping phase of the Eishin project consisted of defining a pattern language. The earliest sketch looked like this:

The finished language was longer and more detailed. Here's an excerpt:

In spirit, this is similar to a breadboard. It defines the elements of the project and how they're related. But a pattern language expresses far more relationships across more dimensions at a wider variety of scales.

At Basecamp and in Shape Up, we talk about flexible scope that enables a team to build "some version" of an idea within a fixed budget. That's exactly what the pattern language is doing here. It defines the relationships that qualify a structure as being "some version" of the design. It specifies a space of possible physical configurations, not one specific configuration. (This is what shaping work at the right level of abstraction is about.)

Here's an example of how adaptable the pattern language is. Later in the process, after his team did the equivalent of betting by defining a construction budget (an interesting topic for another day), they started to work out the specific configuration of the design.

First, they just drew out a possible realization of the language as a configuration of patterns:

Then, orthogonal to the first drawing, they mapped the features of the land to identify its affordances, constraints, strong points, and areas needing repair:

This presented a major design task: how to find "some version" that would fit to the reality of the land.

This drawing of the final design shows how they managed. All the relationships from the language are still present, but they are now embodied in a specific configuration that fits the constraints of the site.

This is profound. The "specification" — the pattern language — had so much latitude that it could lead the team to arrive at a configuration nobody could anticipate, while still satisfying the system of relationships that make it fulfill its purpose.

Inspired by this example, I'm experimenting with shaping work for Basecamp 4 as pattern languages.

For example, we're playing with a feature tentatively called My Place. My Place is a place to quickly capture things you want to remember to follow up on and track things that are private to you.

Among the patterns are things like this:

1. Parallel universe — Hide app navigation and notifications while there so it's easier to focus
2. Always at hand — Jump there from any screen in the app
3. Flat list — Instantly add to the top, no filing or categorizing necessary
4. Visible completed items — Completed items pile up to feel accomplishment
5. ...

I don't know where the button should go to get to My Place. Or how it should be laid out. To determine those things, we'll need to look at the "land" — the pre-existing constraining structure of the rest of the app — to see where there's room and how this might fit in.

There's so much more to explore with this topic. But for today I wanted to at least draw the connection between the shaping phase and the form of the pattern language. I expect to learn more as I get more experience shaping BC4 features this way.