Christopher Alexander and Living Structures

From AOCWiki

The purpose of this session was to discuss Christopher Alexander's The Nature of Order. In that series, he gives 15 properties that, he claims, characterize living structures. (He uses a quite broad notion of "living": anything that resonates deeply in our soul, which may include, for example, landscapes, rocks, certain buildings.) We hoped to explore two questions:

Q: Do these properties fit with our existing agile structures? (Processes, code, ...)

Q: Can we use them to improve our structures?

We had one big obstacle: the convener (David Carlton) had only read one and a quarter volumes of the four-volume series, while none of the other participants had read any of the volumes! We didn't let that stop us, though: we went through the list of properties, and thought about what agile structures they brought to mind.

Alexander uses "center" as a technical term referring more or less to any coherent entity. (Typically, centers are made out of smaller centers, which are made out of still smaller centers, ...)

Contents 1 The properties: 1.1 Levels of Scale 1.2 Strong Centers 1.3 Boundaries 1.4 Alternating Repetition 1.5 Positive Space 1.6 Good Shape 1.7 Local Symmetries 1.8 Deep Interlock and Ambiguity 1.9 Contrast 1.10 Gradients 1.11 Roughness 1.12 Echoes 1.13 The Void 1.14 Simplicity and Inner Calm 1.15 Not-Separateness 2 Conclusions 3 Postscript

The properties:

Levels of Scale

• Rhythms at different time scales: TDD (minutes or even seconds) / pair swapping (a couple of hours) / standup (daily) / iterations (weekly) / releases (quarterly?)

• Scales in code: blocks, methods, classes, modules, programs.

Strong Centers

• Information radiators (or perhaps the metrics that they represent).

• The iterations that work is divided into.

• The developer team; the customer team.

• Blocks, methods, classes.

• The idea of getting the code into production.

• The question "what is the goal?". Or any goal motivating some work.

Boundaries

This property is more subtle than it might seem from the title: Alexander prefers thick boundaries, boundaries that are significant enough to be a meaningful center in its own right. E.g. a wide frame around a window exhibits this more strongly than a narrow frame.

• Iteration planning meetings.

• Guarding new stories from being added to iterations.

• The scrum master.

• Public interfaces or abstract interfaces in code.

• Braces, whitespace in code.

Alternating Repetition

• Plan, do, reflect.

• Write, test.

• The heartbeat / rhythm of a team / iteration / ....

Positive Space

This is an area that is between other centers, that is coherent enough to be a center in its own right

• Whitespace in code.

• Failing / missing tests.

Good Shape

• Basic examples in code: simple straight-line code; a branch; a loop.

• Methods that are decomposed into smaller ones with the above properties.

• Well-crafted, small stories.

Local Symmetries

• Having a consistent length for iterations or for stories.

Deep Interlock and Ambiguity

One picture that motivated us here is where two beams cross (at right angles) in a log cabin. The place where they intersect is part of both the logs, but is a center in its own right, and its power comes from that interlock, from its ambiguous nature as belonging to both those centers.

• Having core principles that give us freedom to experiment while remaining grounded.

• The fact that we don't have to settle everything up front: we can resolve ambiguity at an appropriate time via interlocking centers. (E.g. the customer and developer.)

Contrast

• Red vs. green.

• Done vs. not done. (Avoiding "90% done.")

• Having a single responsibility for something.

• In scope vs. out of scope.

Gradients

• Iterations zero/one vs. later iterations.

• A new team versus an experienced one.

• Velocity improvements.

• Mounting technical debt. (A gradient that is a negative indicator.)

Roughness

• Things that we notice that are opportunities for continuous improvement.

• Beware false precision and overengineering. (Hence the use of timeboxing.)

• Don't squash individuality.

• Risk.

• Don't try to have a perfect architecture / specs, or a sterile one: do what's actually useful.

Echoes

• The notion of planning showing at different time scales.

• Feedback loops.

• Multiple teams (within a single organization) working with similar (but not identical) processes.

The Void

• Go home!

• Slack, reflection.

• Free / unstructured time.

• Gold cards / 20% time.

• Open space.

Simplicity and Inner Calm

• Do the simplest thing that could possibly work.

• Elegance is the simplicity on the far side of complexity.

• Refactoring.

• Eliminate waste.

Not-Separateness

• Organic software development.

• Creatively solve problems a bit at a time.

• Work in small steps, testing against reality.

Conclusions

The above suggested to us that the answer to the first question, whether these properties were compatible with Agile, was "yes!" Though, for all we know, an expert in a high-ceremony practice could just as easily map these properties to that practice as we did to agile; they may be vague enough that anybody can map them to their favorite practices.

We didn't really talk about the second question much, but agreed that it could be useful to understand: e.g. when modifying your practices in a retrospective, when growing from one team to multiple teams. It didn't help that I (David Carlton) had only read the beginning of the second volume, which is the one on how to dynamically evolve these properties.

Postscript

After the conference, I was surprised, when reading further in the second volume, to see Extreme Programming mentioned by name in the book! I copied the relevant quote here.

I wrote a couple of blog posts inspired by these ideas, one on living code and another on agile processes.