Digression on the Objectivity of the Fifteen Properties

Christopher Alexander expressed a strong moral conviction that what he called living structure was good, and a lack of it was bad. The way to create living structure, according to Alexander, was through successive applications of (again, what he termed) the fundamental differentiating process, each step featuring one or more of these properties as structure-preserving transformations.

Whether living structure is a real phenomenon—and furthermore, whether it is immoral not to create it when you have the opportunity—are assertions you can have a genuine, good-faith debate about. You can even argue over whether or not a stepwise process of incremental differentiation is necessary to produce it (to the extent that it exists in the first place). That these fifteen properties are present in the built environment, in greater or lesser degree, is not as negotiable. They are conspicuous features of the geometry of the space in question; you shouldn’t have to go digging into the drawings to perceive them. They require neither a certification in architecture, nor any professional interpretation to recognize. The only training necessary is the list of properties itself, with handful of examples, that anybody can memorize in an otherwise idle afternoon.

As I age, I inch farther toward the position that any sufficiently sophisticated and/or esoteric rationale for imposing one’s will onto the public is indistinguishable from arbitrary. While said rationales need not be inherently disingenuous, they will nonetheless often be construed as such by the public. Where I’ve landed currently is what I’ll call the Einstein Paraphrase: make your rationale as simple as possible, but no simpler—where “simple” not only denotes few moving parts, but those that remain are familiar. If you can’t ground your rationale in language and concepts that ordinary people understand, that’s a sign you don’t understand it very well yet yourself.

Preface to Chapter 6

Writing this chapter has been mixed up with developing the augmented archive at the.natureof.software. The goal, as I mentioned previously, is to provide a space for the community of subscribers to read the entirety of the work in one place, as well as—eventually—discuss and annotate it, and further distill the concepts into material that can be applied directly, and where applicable, programmatically. This is still a work in progress, with a handful of items outstanding—in no particular order—to reach “minimum viable” status:

• The visual design, which I will undoubtedly noodle on ad infinitum,
• generated / boilerplate content, and the infrastructure to support it,
• some mechanism that syncs subscribers from the newsletter to the website…

…and later on, when I implement them, dynamic elements and structured data. Whenever possible, I will be streaming these interventions on Twitch and YouTube.

The current list of subscribers, as of this writing, will have access to the.natureof.software. through an initial manual sync. To log in, use the same e-mail address where you get the newsletter delivered. I want to underscore that this site is still lumpy as heck and I am actively hacking on it. I'll try to get automatic syncing online as soon as possible.

And now, enjoy Chapter 6: Good Shape.

In the chapter in Nature of Order introducing good shape, Christopher Alexander admitted that it was one of the more elusive of the fifteen properties. Not only is it the only one of them whose name explicitly expresses an opinion, he defined it in terms of itself: analogous to strong centers, a good shape is made up of good shapes. He nevertheless got more specific with an enumerated list of criteria for what he meant:

1. High degree of internal symmetries.
2. Bilateral symmetry (almost always).
3. A well-marked center (not necessarily at the geometric middle).
4. The spaces it creates next to it are also positive (positive space).
5. It is very strongly distinct from what surrounds it.
6. It is relatively compact (i.e., not very different in overall outline from something between 1:1 and 1:2 — exceptions may go as high as 1:4, but almost never higher).
7. It has closure, a feeling of being closed and complete.

The Nature of Order, Book 1, Chapter 2.6, p. 183.

Introductory Note to Chapter 5

I started this chapter maybe a few days before Halloween, and shelved it temporarily to take care of something, thinking I'd get back to it in a week. This, I sheepishly admit, did not happen as soon as I'd have liked it to.

What I was working on lay at the nexus of probably three separate decade-spanning threads of inquiry. My professional focus is, and has been for at least this long, about comprehension: helping people understand complex situations so they can make intelligent decisions and operate as a unit.

Now, I write documents and do slide presentations just like the next tech consultant, but I have had the growing impression, especially as the Web matures and we tuck into the early-mid 21st century, that the capabilities of digital media are still going miserably underutilized.

I have remarked in a number of places that if you take a garden-variety webpage and you shave off the navigation bar and the various insets, headers, footers etc., what you get is scarcely distinguishable from a Word document, which itself might as well be a printed piece of paper. Exceptions to this are mainly when the Web is being used as a delivery mechanism for software, rather than content. The latter is my source of interest, specifically dense hypermedia content, where traversing links—which themselves take many forms—is a major part of the experience.

When I say dense hypermedia, I mean it in contrast to sparse hypermedia, which is what we get with the Web as it is currently tooled: a lot of text and not a lot of links, and moreover a lot of things that could be links but aren't.

• Hiving off details, digressions, parentheticals: hypermedia (text or otherwise) could be unparalleled in its ability to get to the point. When you write an ordinary document, you have to include all this ancillary information inline: em-dash asides, parentheses, insets, marginalia, footnotes, endnotes, and so on. Making this content optional means busy people don't have to read any more than they need to.
• Providing background information: the same mechanism used to abridge digressive details also works to discreetly help the reader get up to speed if they aren't familiar with some aspect the subject matter—say a particular concept, term, or entity. No need to be seen asking “dumb questions”.
• Reusing content: not just to save time, but to avoid creating duplicates, ensuring all referring documents remain accurate when said reused content is updated.
• Mixing media: something the Web is already pretty good at: integrating text, graphics, audiovisual, and interactive elements. Although…
• Providing computable representations of structured data: mixing media, especially interactive visualizations, depends on data that can be used directly by the computer without any additional (human-powered) formatting or interpretation. Structured data may be represented in a table, record set, or chart for human consumption, but without formal structure and labels, it can't be repurposed for computation. We solve this by generating variants—ways of asking for the same content in a different container—and by embedding this formal structure into the documents themselves.

When I made a new website in 2007-2008 (after not having one since around 2002), I was determined to write it under a “proto” dense-hypermedia paradigm (I hadn't yet come up with the term): short documents, never more than a screen worth of content, completely stuffed with links—every thought gets its own page. This, it turns out, is really hard, so I eventually gave up and started writing ordinary essays—apparently hundreds of them.

The problems I was running into at the time reduce to the fact that the overhead of managing the hypertext got in the way of actually writing it. Specifically:

• If I wanted to link to something that didn't exist yet, I had to stop and think up a URL for it. Now, wikis handle this, but they do it badly, as URL naming is consequential, and half the reason for so much link rot on the Web is people renaming them willy-nilly.
• Then, I had to create a stub document so there was something to link to. Or otherwise, disable the inbound links so there is no route to a nonexistent or otherwise unfinished document. Again wikis do handle this, but also badly. The real problem here though was just keeping track of the stubs that I had started but not yet finished.
• The surface area of hypertext is surreptitiously huge. I would set out to write something without the faintest sense of how much effort it would take, in part due to raw overhead, but mainly because there's an invisible dimension that absorbs all your effort.

Conventional documents are simultaneously bigger and smaller—or, perhaps, thinner—than comparable hypertext networks. Due to the constraint that all parts of an essay, for example, have to show up on the page, it has a relatively well-defined scope. Hypermedia, by contrast, has an infinite number of nooks and crannies in which to sock away more stuff. It is actually reasonable to expect the amount of work involved in any hyperdocument to be proportional to the square of a comparable ordinary text. The formal reason has to do with graph theory, but the intuition is that there's another dimension that we can't see when we're looking at a document—itself strictly-speaking a one-dimensional object—because we're looking “down” at that second dimension edgewise.

In the last 15 years, I have developed techniques and tools that solved the bulk of the aforementioned problems, with the ultimate aim of returning to the dense hypermedia question. Outside of a few specialized engagements, though, I did not tackle it head-on until late 2022. (I had one of those “if not now, when” moments.) Remarks:

• Content reuse is essential, if for no other reason than a big chunk of linkable content can and absolutely should be reused. It's a whole universe of extra work otherwise, and a wild one at that. Microcontent and metadata is individually small enough to deem it not worth the candle to look up instead of writing anew, but (especially since it is linked together too) adds up to a formidable time suck. I spent about a week and a half just consolidating a bunch of duplicates I had generated over the last five years or so, a debt that had finally come time to repay.
• The tooling and infrastructure I had written got quite a workout. In some cases it was because there was a particular effect I wanted to achieve that I hadn't previously anticipated in the tooling, in others because I was trying to fit together parts that hadn't previously been put together, and others still because of reconciling changes with third parties. As I wrote elsewhere, I probably stepped on every rake in the system, but the good news is, I'm now out of rakes.
• There is all sorts of hidden work in the final presentation. Once you create all the parts and gather them up, it might not be immediately obvious how to arrange them. You will need time to do a final curatorial packaging of the artifact. This could be palliated somewhat by establishing a set of archetypal hypermedia artifacts, but those archetypes are only going to be identified by stumbling around in the dark.
• I'm actually inclined to say that the logic of deliverable = artifact is anathema to the spirit of hypertext. It costs asymptotically nothing to add a single connection or piece of content to a hypermedia network, such that to cut all that activity off because the product is “done” seems like a bad idea. While there should perhaps be checkpoints of “done-ishness”, these artifacts (if we can call them unitary artifacts) should never really be considered fully “finished”.

The way I did this dense hypermedia project—and the wisdom of this is still debatable—was to write out the full-length document, and then start bucking it up, separating it into gloss versus details. There is also a completely stripped-down, structured version of the rationale itself, which is linked throughout the document(s).

What I have found in my career—and what ultimately motivated me into this line of inquiry—is that technically-inclined readers insist on details that cause the rest of the population—which includes business leaders—to bristle. What little technical discussion you absolutely cannot scrub away is going to have to be nerfed with a like-I'm-five explanation of what the detail is, and why I insist on bothering you with it. The technical people will naturally find this boring and remedial. You just can't reconcile these two audiences with the same document, but you should be able to with a hyperdocument, even if it's just to share content common to both audiences without having to make a duplicate copy of it.

What does this mean for you, a Nature of Software subscriber?

• Well, for one, the resumption of a monthly publishing schedule, as the thing that has been eating my waking life for the last several weeks is now done, and monthly seems to be what I can ordinarily manage.
• But more importantly, since I just ironed out the kinks on a whackload of new capability, I'm setting up a second archive on the.natureof.software where I'm going to put augmented versions of published chapters and other resources, to which all subscribers will have access.

This project is, at root, an attempt to make Christopher Alexander's The Nature of Order relevant to software development, while at the same time abridging the reading task by an order of magnitude. This is still on track. Indeed, I suspect that part of the reason for friction around the uptake of Alexander's ideas is that there is just so damn much material to read. While the main artifact here will still be a book-like thing serialized as a newsletter, there is still plenty of opportunity to both compress and enrich the message even more. Alexander's work is furthermore full of concepts and processes that can be spun out as structured data to remix and build upon.

In general I endeavour to move into the hypermedia space and live there permanently, such that conventional documents like the one you're reading are projections of higher-dimensional structures, flattened and desiccated for less dynamic media. The newsletter will continue, of course, but it will be a snapshot of what's happening online. That's the goal, at least.

At the time of this writing, there is nothing on the.natureof.software, because I just bought it. There are a few things I need to do before I have something minimally viable up there, like setting something up to sync accounts, and making an index page. Then I can work on certain data products like a concept scheme (the bulk of which I have almost certainly written down elsewhere), and interactive capabilities like collaborative annotation. Definitely by next issue there will be something there to log into.

And now, enjoy Chapter 5 of The Nature of Software: Positive Space.

The quintessential figure-ground inversion: the Rubin vase.

The third and final chapter in the cluster I am calling “the zone between two centers is also a center” is positive space. This refers to figure-ground inversion, or the shaping of what is typically called negative space—that is, the part on the page without the ink—into something meaningful. The phrase positive space is an Alexanderism, and he meant something a little more specific, that (in the case of architecture) if you could magically swap wall with air, the resulting shape would still be coherent, and more or less convex. Think the three-dimensional analogue to the Rubin vase, the FedEx logo, or an Olly Moss poster.

Alternating repetition is the second of three consecutive properties in The Nature of Order which make little sense if you apply them directly to software. It is curious that Christopher Alexander arranged them consecutively, because, as I have mentioned in the previous chapter, Boundaries, this and the following chapter (Positive Space) share a sort of meta-characteristic, which can be pronounced like “the space between the centers is itself a center”.

Given this state of affairs, I am going to use this space to talk more about this meta-property, and how it is inflected by the original geometric property from the book. This is of course after I tell you what it means for buildings.

In Buildings

Buildings tend to have, for instance, structural elements that repeat. Whether they are piers, or bays, or vaults, or columns, or joists, or rafters (they don't have to be load-bearing either, they could be dormers or even ornaments), buildings are full of features that are usually evenly-spaced, identical copies of an elementary structure. Alexander argues that the space is more whole when the gaps between these features are discernible features in themselves.

Christopher Alexander approached his fifteen geometric properties from a roughly phenomenological standpoint. They are “fundamental” in the sense that they are sufficiently differentiated from one another for each to warrant its own distinct treatment. It is nevertheless possible to view commonalities among the properties, suggesting that they can be broken down to even more elementary concepts. Alexander himself hinted at this when he proposed a separate set of eleven properties for colour. Some years ago, I even considered a grouping of the properties in terms of their pertinence to information theory.

A few of Alexander's properties share a characteristic that can be articulated roughly like the space between two (or more) centers is itself a (strong) center. Boundaries is one such property. Alternating repetition and positive space, which also happen to constitute the next two chapters, have the same characteristic as well.

In my information-theoretic meta-categorization scheme, I put boundaries in a separate category (conveying a signal) from alternating repetition and positive space (compression). This demonstrates that there is more than one way to cluster the properties. We expect this, however, since we're ultimately trying to bucket continuous phenomena like space, colour, and feeling into discrete concepts and conceptual structures.

Boundaries in Buildings

Recap

For those of you who just arrived, this project is about reconciling the work of the recently-deceased architect Christopher Alexander—inventor of pattern languages—with the craft of software development. Patterns were a big hit with us in software, but we didn't keep up with current events—and by current I mean 26 years ago. You see, Alexander personally renounced patterns. Said they weren't good enough. He told his audience he was working on something simpler—much simpler, and much more profound. And that's what we're exploring here.

This essay explores the second of the fifteen properties from Alexander's magnum opus, The Nature of Order. If you don't know what I mean by that, then read the introduction, as well as the first chapter, Levels of Scale.

What is a Center?

If Christopher Alexander's latter-career methodology has a centre, it's the center. A center can be understood as a region of space (or spacetime if you like), that is differentiated from its surroundings somehow. A center is identifiable; you should be able to point to it, maybe even name it. A center has thing-ness. It need not, however, have a crisp boundary: centers, according to Alexander, are field-like. This tracks, because they don't call it the spacetime continuum for nothing.

A center, therefore, is kind of like a “minimum viable thing”: any thing is also a center, and if it's not a center, then it's a non-thing. The reason why one would bother introducing a new term center and not just say thing is to call attention, for one, to what I just wrote about the fuzziness of boundaries, but also to further specify that centers are recursive: centers are made of centers, and compose to make up other centers.

Preface to the Fifteen Properties

The program of this serialized essay is to go through the fifteen properties/transformations that Christopher Alexander defined for buildings in The Nature of Order, and try to map them onto software and software development. I do not promise to address them in the sequence they appear in the book, though so far it looks like the book's sequence is fine for now. I also do not expect the properties of software to match up perfectly 1:1 to the properties of buildings, but I am nevertheless proceeding through the properties as given to try to see how well, or even if, they fit. I will address any amendments in a conclusory issue.

This first property, levels of scale, which is also the first one in the book, is fortunately an easy one.

Levels of Scale In Buildings

What did Christopher Alexander mean by levels of scale? Literal levels of literal geometric scale. That is, the architecture has prominent features that are big, medium, small, and tiny, and potentially many levels in between. We ask:

Preface

This project was conceived in part by the overwhelming response to what I ended up calling a retrospective of Christopher Alexander's work at the time of his passing. In it, I referenced a keynote address he gave in 1996 to a room full of programmers. The keynote covers three major points:

1. Patterns are inadequate (for producing what he called living structure),
2. A new theory replaces—or rather, subsumes—pattern languages,
3. Software people are uniquely positioned to help.

For starters, there are an order of magnitude more programmers than there are architects.