Or, indeed, to look at Alexander's work since this book, which has gone in a direction very similar to the programming world. In "The Nature of Order", Alexander shows how the idea of "good design" is actually best analyzed as just the output of "good process": design is about how a thing unfolds over time and becomes more itself through gradual refinements and responding to its environment.

The bigger complaint about software patterns is that, unlike Alexander's original patterns, they are merely tools useful to build any kind of program. Alexander's patterns were meant to only be useful in building humane places with humane processes. You literally could not build a mass prison with the construction methods he describes, because they aren't amenable to mass production, design from afar, or economies of scale.

Exactly the opposite is true of our usual application of "software patterns". They are often used to produce software that is inherently immoral. Alexander's patterns describe an environment of decentralization of decision-making about both architecture and the community it inhabits. Meanwhile, our "software patterns" embed a centralized power structure both in the code (architect->team lead->junior programmer) and in the world now increasingly controlled by the whims of Silicon Valley founders.

I wonder what it would look like to describe low-level primitives of computation, similar to Alexander's new low-level architectural methods, which actually made decentralization of power a reality and resisted economies of scale. They certainly wouldn't look like the Gang of Four patterns.

> Meanwhile, our "software patterns" embed a centralized power structure both in the code (architect->team lead->junior programmer) and in the world now increasingly controlled by the whims of Silicon Valley founders.

None of these things is obvious to me. In fact, this whole paragraph veers in the direction of a conspiracy theory. The rest of your post is quite interesting and I agree that the design of our software should tend towards the human and humane.

> Exactly the opposite is true of our usual application of "software patterns". They are often used to produce software that is inherently immoral. Alexander's patterns describe an environment of decentralization of decision-making about both architecture and the community it inhabits.

You should expand on this.

I certainly don't mean to imply a conspiracy theory, any more than Alexander would say that the past century of poor architecture is deliberately brought about by a conspiracy of architects. It's simply a case of the environment bringing about bad results naturally.

His critique of architecture is this: the quality of a building comes from a process which has to unfold over time and take into account very minute preferences of the kinds of people who will actually inhabit it. A good house design can't be measured by the plans, but only by living in it and seeing what kind of life occurs to the people who are there. Therefore, if you build it by one person's design, or because the renderings look nice as a 2d composition or as a 3d model, or to reduce costs by repeating the exact same things over and over, you will necessarily end up with a bad building. It won't be bad on purpose, but the power structure of the process that built it will have made it bad. (Maybe an architect wanted to win an award, or a developer wanted to sell the properties quickly without worrying about the owners' long-term experience, etc.) And if you want a better building, instead of arguing about design, you should just find a process where more of the decision-making is made by the kind of people who will inhabit the house.

The same is true of software. I do not think most people set out to make bad software. But Conway's law tells us that the result will reflect the organization and process by which it was created. If the process of creating the software is embedded in a large corporate structure where VPs are fighting, that politics is necessarily felt by developers and even embedded into the system. If the process of creating the software is embedded into a VC unicorn and its only chance of growth is to destroy local communities or mistreat workers on a large scale, that will happen.

This is even true just for the people building the software. I've worked at companies where the design team had the power, where the engineering team had the power, or where the project management tool had the power. The same people might work with the same goals, but in these three environments they will produce three very difference pieces of software. And I've worked at companies that had the power to trick money out of customers, which soon replaced the desire to actually provide customers any benefit, and produced its own unique form of engineering environment.

Alexander's critique is aimed at the very idea of "scalability": any one person or process who can determine the way architecture (or software) behaves for thousands of people will get it wrong. Not because the person is bad or the decision is inherently wrong. But because no one decision could possibly be right for all of those people.