Software Hasa Body

I wonder if the concepts that Alexander proposes ("center", "quality", "beauty", "wholeness", even "utility" to some extent) have their full meaning in a world with a geography, bodies to walk through this geography, and an embodied memory to remember the walking paths.. Transposing these concepts into a world such as software engineering which has so far no geography, no bodies and no embodied memory is a risky affair (but we love risk, don't we?). Where is the fractality of software? Where are the centers? Where is the latency (in "latent centers")? What does a distance mean in a software program? -- JeanMichelAndre

Good questions. In hopes of teasing out better ones, let me risk some partial possible answers. The questions suggest that in software engineering there are no bodies, no embodied memory. What about us software engineers?

We even sometimes say that we walk through software. When we do, our embodied memory remembers the paths. We use motion metaphors all the time:

To get the Address string, we go to Person and then to the Address object. You can go to the PeopleCollection? to find a person. Go to the Profile to get to the PayRate?.

Is this geography? Not clearly, but it must be geometry, or UML and similar notations wouldn't work.

Your idea that there are some walking paths through software and that these paths can be imprinted in our software engineer memories is attractive. Sometimes it's a long road to go from a fuzzy requirement set until an efficient and user-friendly solution. And 'design patterns' can provide useful short cuts along this journey.

Is software fractal? Well-crafted object software seems incredibly fractal. Sometimes you send messages for ages, drilling down and down until finally someone does something.

I'm sorry but I don't see any fractalitude in your example. Can you develop further?

Where is distance? Sometimes all that drilling down seems quite natural. Sometimes it seems you have to "go a long way", "go around the Horn" to get from where you are in your program to where you want to be. To the extent that these metaphors work, it's because there is something in common between what Alexander talks about and what we programmers do. That, I think, is why Cope, and Gabriel, and other Alexanderites, respond so strongly to his work: there is something in common.

On the other hand, I strongly suspect there are places where the connection breaks down. Alexander, if I understand him, likes lots of similar but different pieces (fractalitude again). In software, we mostly do better when we make things that could be the same be the same. I heard Alexander speak at OOPSLA, in a huge rectangular conference room. He felt there was nothing of QWAN in it.

As a software guy, I had to admire the incredible reuse of those regularly-spaced little round can lights ... the billions of reused concrete blocks ... hundreds of chairs all in neat rows. But the room was UUGGLLYY!

The space could have been made more beautiful. I wish someone would try. But I'm not yet certain whether doing the corresponding things to software would give it QWAN. (And certainly I'm not saying that the Alexandrians are saying otherwise ... just that we should look to him for ideas, and place them properly in our geography, according to our software-sensing bodies.

I deeply agree again. The metaphor fails exactly here: if we, software engineers, are able to draw from our experience some recurrent patterns that can help us to build successful programs, these patterns are relevant to technical mastering (how do computers work, what are those language idiosyncrasies, what kind of components will have a chance to be reusable, etc.) and not to patterns "deeply embedded within our cultures" as architectural patterns are, according to Alexander.

To sum up, the metaphor works until we touch to the heart of Alexander's contribution: QWAN, beauty, wholeness. At this point, it fails. And, to me, the reason is the fateful disembodiment of software engineering, or, if you prefer, the replacement of flesh and blood by silicon and bits, and sentences by instructions. -- JeanMichelAndre

If anything, IMHO the lack of physical world constraints merely increases the possibilities, rather than limiting them as you suggest. It just makes it that much harder for us to ferret out the shapes and bodies from the infinitely larger quagmire of possibilities. Instead of seeing a closed door and assuming it's a dead end, we have to open them and explore them more thoroughly. It's a lot of work, and a lot harder to do a good job. Rather than looking so intently for dead ends, one must look more carefully for open doors, and ways of opening doors that are closed. Concluding they must all be dead ends seems woefully premature however. It just requires more diligence, and more patience, to wade through a much larger sea of thought than of physical space.

I think the question teased at here is "Does software have life?". Of that I would agree to a "kind of life", and then be able to reach out and agree that software has "a kind of body". But, do not ask me if software has soul, as that is more complicated, unless in the sense that music has soul...

CategoryPattern