That's an excellent summary, and I think it explains what many people (myself absolutely included) got a bit wrong when patterns first became popular in software development some years ago. While I managed to avoid the trap of pattern-itis and try to fit everything into some pattern or other, I still worked with the oversimplification that patterns were simply about a language, a way of communicating. DDD emphasised that very strongly, and it has value, but to see it as only that means missing the vast scope of the original work.
I think most people read books on software patterns and heard about the original inspiration, and (without having read it) assumed it was the same "but buildings". In reality, it is as much a work of philosophy and sociology as it is about architecture - it's about lives and how people fit together more than how bricks fit together. It stands in a long tradition, Le Corbusier, for example, deriving systems for living and modular approaches to constructing space such as the Unité d'Habitation.
It would be fantastic if we could get software people to read this kind of thing before they see what it's inspired in the software world - there's so much more to learn from disciplines older than ours (which is effectively all of them). A more comprehensive theory of building software systems (based on the human aspects, the social, etc., rather than the dry economic and project-management aspects comprising most formal books on such things) seems like a significant step in our little world.
> it's about lives and how people fit together more than how bricks fit together
That's a great way of putting it!
> Le Corbusier, for example, deriving systems for living and modular approaches to constructing space
I agree the comparison is apt, but I much prefer Alexander's humane, bottom-up, anarchistic approach than Le Corbusier's authoritarian high modernism.
Reading The Oregon Experiment is great context for A Pattern Language, seeing the way they envisioned the pattern language being used by a community. And the kinds of organisation they needed to couch it in, the way they needed to change the budgeting process to enable many more smaller projects, the way they co-opted staff and students into planning groups rather than have a siloed professional office.
But, sadly it doesn't seem like this approach has been influential. I can't think of many other places that work this way! So while I do also wish more software people had read and appreciated this work, I don't think it's the immaturity of the software industry that prevents us from appreciating these ideas.
In the introduction to A Pattern Language, the authors write "towns and buildings will not be able to come alive, unless they are made by all the people in society". I wonder if this is also true of software.
I agree entirely on Le Corbusier, while I love the eventual outcome of his work in many senses (aesthetically certainly), his approach to actual people was (as you say) far less humane than Alexander. Alexander I think saw himself as a part of "the people" - from what I know of Le Corbusier, I don't imagine he did.
I've not yet read The Oregon Experiment (it's in one of the waiting piles) but I've skimmed it. Funnily enough, the comparison you make around changing budgeting processes to enable smaller projects, having users working as part of planning, etc. reminds me of some of the original intents of agile before it was co-opted. For agile to work it couldn't just be isolated as software delivery - it had to change the organisations it worked with/within. I remember having just such an argument many years ago about governments building software using ostensibly "agile" approaches, and yet still requiring three-year budget approaches from the national treasury - they simply weren't compatible!
That final quote is wonderful, and I do feel the same about software in many ways - all the true wonder of computers and the things they can do for people will never really benefit everyone fully unless it spans the national, the corporate, and the personal.
I think most people read books on software patterns and heard about the original inspiration, and (without having read it) assumed it was the same "but buildings". In reality, it is as much a work of philosophy and sociology as it is about architecture - it's about lives and how people fit together more than how bricks fit together. It stands in a long tradition, Le Corbusier, for example, deriving systems for living and modular approaches to constructing space such as the Unité d'Habitation.
It would be fantastic if we could get software people to read this kind of thing before they see what it's inspired in the software world - there's so much more to learn from disciplines older than ours (which is effectively all of them). A more comprehensive theory of building software systems (based on the human aspects, the social, etc., rather than the dry economic and project-management aspects comprising most formal books on such things) seems like a significant step in our little world.