Skip to content

Instantly share code, notes, and snippets.

@sleepyfox
Created January 10, 2023 15:21
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save sleepyfox/0521e311686a5fc4585db9afe2c81b66 to your computer and use it in GitHub Desktop.
Save sleepyfox/0521e311686a5fc4585db9afe2c81b66 to your computer and use it in GitHub Desktop.
Alexandrian Architecture
author: @sleepyfox
title: Alexandrian Architecture
date: 09-Jan-2023

Alexandrian Architecture

My New Year's resolution: I am not going to talk about Micro-services.

Monoliths vs. Micro-services is the software architecture equivalent of "Would you rather fight one horse-sized duck, or fifty duck-sized horses?"

I was recently reading a software book[1], whose forward was written by Christoper Alexander. It was an interesting read, because Mr. Alexander was quite bemused to read in the late 90s that his name was de rigueur in OO programming circles, quite unbeknownst to him, until he was asked to review a book on programming.

One of the many interesting things that he said in his forward was that the Programming Patterns movement was inspired by his early work, like the book 'The Timeless Way of Building', published in 1979 - https://en.wikipedia.org/wiki/The_Timeless_Way_of_Building

He lamented that his own research had moved on significantly since those earlier works, and in particular much of the progress had been made since his company had moved from just architecture, to being both architect and builder.

This for me echoes my own experience in the early 2000s, that being an architect is not enough. If one hands down scrolls of UML diagrams from one's ivory tower one is not a true architect. One cannot understand how architecture affects the developer, the customer, the world, unless one possesses the intimate technical knowledge of what problems the architecture is actually solving (or not, as the case may be). One needs to have deep empathy with the worker, and the customer, if the designs for the work are going to be both valuable (for the customer) and easily built (for the worker). This cannot happen unless one is also doing the work, at least some of the time. I don't know what the minimum is, but I'm guessing it is at least 20% of the time, maybe more.

This [success] has come about in large part because, since 1983, our group has worked as architects and general contractors. Combining these two aspects of construction in a single office, we have achieved what was impossible when one accepts the split between design and construction.

I cannot stress how important this is.

People talk about software architecture like it is something different and distinct from coding, from program design. There are books on Software Architecture, and conferences. This is a pernicious fallacy.

The reality is that software design is fractal. At each level of design, from the individual line of code all the way up to the largest of system of systems, the same principles are at play: coupling, coherence, separation of concerns, reduction of duplication, making interfaces understandable and discoverable, locality of influence, minimising complexity.

Architecture (of software) is not its own field, with separate rules and principals, practices and techniques. It is just programming. Programming and programme design - in the large. Anyone who tells you different is trying to sell you something.

[1] Patterns of Software, Richard Gabriel, Oxford University Press, 1996.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment