Software Patterns Arent Alexander Patterns

ChristopherAlexander's patterns have some purposes and qualities that software patterns as we know them don't:

They're geometrical, they happen in space (an Alexander pattern always has a picture).
They're all places where people live and work, or aspects of places, or objects, that people live and work with. In computer slang, they're always for users.
He selects them according to a sense of something he calls beauty sometimes, or wholeness, or life. Or the sense that you (the user or inhabitant) are more at home there, yourself there, alive there, in a place arranged one way compared to in similar places arranged in other ways.
They're about making the world a better place to live in for people in general, not just for architects (or programmers).

Software patterns so far, are about the hidden, abstract structures that programmers, rather than users, deal with. When they're about habitability, they're about habitability for programmers, which is an important thing, but it doesn't have the same moral, emotional, aesthetic intent.

: It could be argued that Software Patterns are not Alexander Patterns, since they deal with different domains of human activity. Another group of differences comes from the structure of the patterns: obviously, they belong to different human activities, and practicioners have different practical needs and ways to describe their patterns.

: In that sense, many pattern systems can be built (meta-patterns), one for each human activity, and, depending on the needs of the users of the patterns, they may be different.

: However, it is important to note that the origin of Alexander patterns was the need to organize a complex group of interrelated solutions to complex problems with many conflicting forces.

: Software engineers should not shy away from learning and reading Alexander's works, since they show how to deal with complex problems with many conflicting forces, something that any software developer can appreciate. -LuisColorado

Alexander's work, starting with NotesOnTheSynthesisOfForm, was about builders being (or, disasterously not being) regular people who lived and worked in and around buildings like the ones they built, and who did the designing as they built, based on the sense of how things were used and how they fit into their surroundings. (He may be idealizing the past some, but I don't think it matters because he's got the start of a good ideal.)

Alexander had at least looked at Richard Gabriel's book, and written a preface for it, when he gave a talk at OOPSLA '96:


        http://www.patternlanguage.com/archive/ieee/ieeetext.htm

In both the book preface and the talk, he stresses how the software patterns movement lacks the moral, for-users intent of his own work, and in the talk he says a little about how software people might move more in that direction.

But how could patterns about software abstractions relate to patterns about what the user sees and deals with? I think an important step would be to make the programmer's experience more in line with the user's by having the programmer actually work on the stuff as it's working, rather than a description of it. Grab it and wrestle it around in the form the user sees it. Like GUI builders a little--but those deal with so little of what's going on. Like spreadsheets--but in those you really just have quick access to abstract descriptions of the individual cells.

In order to have the power of programming, this would require that the user's world and the things available there have that kind of power. The things available on the screen would have to be items in a pattern language of useful things that cover the range of conceptual things users have to work on, deal with and have presented to them. Widgets, yes, but arrangements, flows, live relationships, triggers, overviews, skeins of links, etc., a whole interlocking world of concretized, interlocking ideas up and down the range of scales, in a "language" not just powerful enough to express what programmers do now, but express it gracefully, clearly and useably in a form suited & intended for users to see, touch, work with and live in. And also, a language to address all the important kinds of needs unmet by computers now. It would have to be better for people's lives as a whole--if it was to reach in Alexander's direction.

Software ought to be a kind of performing clay, that you can shape all sorts of active things out of, from worldwide conversations to personal record systems to Fibonacci sequences. At that point we'd have the material; what we'd need to build out of it would follow something like all the conventions of books, diagrams, buildings, road signs, maps, steering wheels, movies--the vernacular of symbolic life analogous to (& overlapping) the one for physical life.

I know this doesn't go very far. I say some even less useful things in a rant at the end (currently) of SoftwareLacksaBody !-) --SteveWitham

: One observation on your initial comparison. One of the goals of OOP and software patterns in general is to ease maintenance. The iterative XP process makes all programming into maintenance, in a sense. With that viewpoint in mind, the inhabitants of software (especially source code) are the programmers and not the users. As for focusing on the needs of users, there's AlanCooper's InteractionDesign for that.

Any method that gets you quicker turnarounds and has you spending more time listening to users than deciding by yourself what's good for them, is a more "vernacular" process like Alexander likes. Yes, programmers inhabit the source code, but that's the non-Alexandrian thing. The source code is different from what the customer, the user, inhabits, and the user is who counts most. -sw

: Consider that great class of patterns called refactorings. They have absolutely nothing to do with the users, only the programmers. In contrast, consider that the extent to which users' needs are involved in software can be encompassed by InteractionDesign, which many programmers seem to think is just interface design.

Seeing, arranging and describing something in a new way (what a refactoring is) aren't things that only programmers should have access to. The whole idea of abstracting and parameterizing classes of things is central to programming and hard to think how to make more natural interfaces to. It's one of the biggest hurdles. But programmers aren't the only people who deal with abstractions. Don't know much about InteractionDesign. -sw

: A detailed comparison of InteractionDesign with architecture reveals its many similarities. Both are "vernacular", both involve asking the user what they want, but neither involves asking the user to make a complete and detailed specification of what they want. Even with Alexandrian architecture, the architect's job involves a lot more than writing up the spec and checking it for consistency. It involves fulfilling needs which the customer is incapable of voicing. This stands in contrast to XP where the customer is asked to fill in the role of architect. InteractionDesigners are Alexandrian architects.

: In a sense, SoftwarePatternsArentAlexanderPatterns because programmers have been shying away from InteractionDesign. In another sense, SoftwarePatterns are AlexanderPatterns and the customers are the programmers themselves.

An important aspect of Alexander is that he doesn't distinguish one customer from another. His main points are about suitability for people in general, that there are just universally better ways. I just can't emphasize enough how viewing ourselves as the customers--designing special environments to suit ourselves--is just perpetuating programming as an elite (or ghetto) with a different point of view, and that's what's anti-Alexandrian about it. Maybe by learning to make more "humane environments" (not to single out TheHumaneEnvironment) for ourselves we will eventually wake up and see our activity as continuous with everybody else's...maybe that's the only path in fact, but as long as our needs, points of view, and accustomed environments are distinct, we're out of grace, Alexander-wise. -sw

Yeah well, the whole 'universal beauty' thing is rather old hat. Perhaps we are "post-Alexandrian"? For example, I'm not sure anyone expects a universal toilet for all humans of whatever gender/size etc? So why assume universals at any other scale? Therefore having software architecture specifically about the programmers, who are probably the only people to interact with the code, is entirely appropriate. I suspect that Alexander would not be quite as utopian as the page creator is inferring. After all the class of users is as much a contextual force as the landscape. The whole 'aesthetics' thing is a bit of a canard. -- RichardHenderson.