Software Lacksa Body

Discussion continued from NooHasNothingToDoWithSoftware

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 ?

These are some of the questions asked about the Noo metaphor by other people than me. I think that something does not work here in the metaphor, and it is worth addressing it. I think that we might find behind these questions that something goes wrong now with software programming which prevents it to produce truly beautiful and whole things. To be short : software lacks a body. -- JeanMichelAndre

To be even shorter, take a look at the three-part series of articles JimCoplien wrote the CppReport earlier this year. They all attempted to take different possible views of what such a body or "geometry" might correspond to in "software space." Nothing definitive was offered up as a solution, but if anything, one might have been inclined to believe that software has too many possible bodies to choose from rather than no body at all. -- BradAppleton

I took the time to carefully read Cope's CppReport articles. While I recognize that Cope did a honest work to address our central question (i.e., what is space for software ?), it seems to me that he did not succeed to provide for a valuable answer to that question. He successively tried to find space first in the code layout, then in the code structure, then in the symmetry of some (specific) pattern, then in the mapping of (some specific) program execution to space, then in recursion, then in the scarcely syntax of some functional programming language, then ...

I see these numerous tentatives to find 'space' in software as an acknowledgement that none of the proposed answers is satisfying per se. My point of view is that the sum of all of them does not provide for an acceptable answer either.

Let's take one of the candidate that Cope seems to value particularly (because it gives it more place than to the others): the symmetry of the HOPP pattern. It's so easy to remark that this particular pattern has a symmetry while so many haven't that Cope should have addressed this issue at first. But he ignores that evident objection and prefers to proposes radically different propositions in its third paper.

It seems that Alexander himself admits this difficulty when he says (reported in Cope's article "Worth a thousand words") : "Software structures do not live in 3-D space". I think that we must hear this sentence not just as an evidence, but as a recognition that this lack of 3D-ness in software is a real obstacle (a kind of epistemological gap) to make a meaningful analogy between architecture and software, and hence to import Alexander's concepts into software.

Admittedly he still proposes a direction where to search for "centers" in software ("what kind of x is there that makes it true to say that every successful program is an x of x's ?"). Humm ... sounds like a new Fermat's conjecture ! :) -- JeanMichelAndre

Well - I read those same articles and came to a very different conclusion. Cope's purpose was to explore many different possibilities for what "space" might mean w.r.t. software. I think you are interpreting Cope's and Alexander's statements too narrowly and rigidly. I saw in those articles more than ample concrete evidence that there are multiple things in software that not only can be perceived spatially (despite their intangibility), but which can be done so in meaningful ways from multiple perspectives.

The complaint that nothing yet has convinced you how to see a physical shape for software is going at it from the wrong end. I think one needs to spend more time going at it from the other direction, not of trying to map software to physical/euclidean geometry so the rules apply, but finding a view from which the underlying notions behind the "physical" centers seem to apply. The important thing to be looking for here is not a 100% literal tangible 3-D shape, but of the corresponding "space" in which these "centers" can meaningfully exist and interact within the context of software. This is what will define the software equivalent of "geometry," not the other way around.

Well, that's Cope, not me who quite honestly tried to find an equivalent to space in software. To me its search did not provide for an acceptable answer - and I've tried to provide arguments to that opinion. To me, that reinforces my doubt regarding whether "centers" (in the spirit of Alexander) can be found in software. -- JeanMichelAndre

Reinforcing doubt is a far cry from proving nonexistence. Some amount of doubt is healthy, to be sure. But let's not jump to the conclusion that a finite number of dead ends proves that all the infinite paths are dead ends, too. It doesn't. If you're still not convinced, or still have doubts, that's fine. But please let's not go declaring the search fruitless for all, just because one of us is getting frustrated or tired or impatient or dissatisfied. Expressing doubt and concerns can certainly help others decide where and if to continue their own searches. That's a good thing. But let's not presume that others can't see their own centers in their own software in their own ways, even if those ways don't seem to work from our own subjective perspective. Just because someone else's "center" doesn't convince you that it "works" doesn't mean it doesn't work for the other person. So remember to keep those declarations within the scope of the proper context instead of expanding them to be more global that they truly are. Otherwise, you're making exactly the same types of declarations as those of Alexander's that you wish to guard against in the first place.

Mathematics lacks a body too, doesn't it, but people speak of beauty in mathematics. (Mostly mathematicians, of course, but still.) A thing doesn't need a body to be beautiful; it needs a form, and software has a form.

It's a point that is still discussed by mathematicians themselves and by epistemologists (in France, there is book of dialogs about that topic between the mathematician Alain Connes and the biologist Jean-Pierre Changeux). Does mathematics expresses truths which are a production of our body, reflecting in some sense the way our body perceives the world where it lives or do these truths preexist to the human being? I don't pretend to have the answer to that question. Anyway, it might happen that mathematical discovery is deeply biologically-driven. I don't think this is the case for software which is mostly driven by technical concerns (which OS/language to use, which libraries, which components, which middleware, how to deal with these bloody browser differences, etc.). -- JeanMichelAndre

I think the problem with software and "beauty" or "wholeness" is that software does not exist for its own sake. At least, the software I work on doesn't. And since its purpose is purely functional, the form it takes is not determined (principally, if at all) by abstractions like beauty or natural order. So, BeautyAintMyBusinessNoSir.

I think the problem with houses and "beauty" or "wholeness" is that a house does not exist for its own sake. At least, the house I live in doesn't. And since its purpose is purely functional, the form it takes is not determined (principally, if at all) by abstractions like beauty or natural order. So, every architect in the world, especially ChristopherAlexander, is wrong.

I agree with the first part of this opinion, but not with the second. Software today does not deal with beauty - but to me, it's because software is still too close to the machines. One day things may be different. Concerning the houses, I don't agree that a house is (or should be) purely functional. It should incorporate beauty, and I follow Alexander when it relies beauty to the human cultural histories. -- JeanMichelAndre

(This discussion is becoming un-beautiful and straying from "Body" in the page title, so I propose we break it into separate topics, as follows.)

1. FunctionalAndBeautiful?: If a house must be functional, why not also make it beautiful? New suburban development houses work but tend to be bland. Compare them to old city neighborhood houses that work and are beautiful. Let us strive for both function and form. Christopher Alexander seems to suggest that function without beauty is lacking in function when he refers to "the unavoidable relationship between structure, fact, and beauty". -- DaveEaton

2. ExternalAndInternalBeauty?: Let us create this beautiful form both externally and internally. External beauty is visible to the non-technical user (appearance, usability, convenience, harmony, etc.). Internal beauty is visible to the technical professional (plumber, electrician, engineer, programmer, etc.). And, high-quality internal beauty can be felt externally (solid construction, lack of bugs, quickness of repairs, etc.). -- DaveEaton

3. ObjectiveSoftwareBeauty?: Just as mathematic beauty tends to visible to mathematicians, I expect that we in software will also come to a "Nature of Order" kind of agreement about what internal software beauty. But, not any time soon. (This is more specific to software than ObjectiveBeauty.) -- DaveEaton

Perhaps also: WhyMakeSoftwareBeautiful?.

But beauty is functional. Understanding this is the key to understanding Alexander. The function of beauty can only be addressed when all the other functions have been addressed. It's at the top of Maslow's Pyramid [presumably MaslowsHierarchyOfNeeds].

It seems to me that any argument for beauty in houses can also be applied to software. Thus, if you think houses should be beautiful then you should think that software should be beautiful. -- RalphJohnson

I'm not sure what you mean by "should." I think that a house ought to be beautiful, because I think it is good for people to see beauty. Clearly, I can't use the same reason for thinking that software ought to be beautiful, because the people who use software don't see it.

The house as perceived by its occupants corresponds, doesn't it, to the software's user interface. I don't think there are any imperatives on the beauty of a house's insulation, say, or the inside of the air ducts. There are certain quality requirements for the unseen portions of a house - I want the plumbing to be as straightforward as possible - but although they may lead to a simple or elegant design, they don't need to be beautiful.

My concern with beautiful software - begging this page's question and assuming that software can be beautiful in some sense - is that I am being paid to create, not aesthetic pleasure for myself, but functionality for others. Beauty is good, but it is not the highest good in most software development efforts. -- TomKreitzberg

And what Alexander is saying is that if it is the highest good in terms of functionality, utility, and usability (etc.) then it will also be necessarily beautiful because it cant be perceived as beautiful by it users in anything other than a superficial sense without also being useful and functional in deeply satisfying ways. So the logic is that analyzing and understanding what the elements are that gives user's this deeper (non-superficial) feeling of beauty about the work-product is germane to making it highly functional - they are intertwined.

Now maybe we don't understand the connection (yet) between what the user's perception of beauty has to do with software that satisfies its customer's needs, but the claim here is not that beauty is secondary to function, but that they go hand in hand in ways that can be difficult to see. And focusing on what the user perceives as beautiful and satisfying can lead to what the architect (who should also be a user in Alexander's ideal model) perceives as such from his or her perspective, and that these two perspectives are also keenly connected.

So while your concern is noted, its also unwarranted because you're not being asked to develop software that's beautiful solely for your own personal pleasure; it's always been about user and satisfying their needs both functionally as well as aesthetically with the same thing(s), acknowledging that they are symbiotic rather than mutually exclusive. And software that satisfied it's users in these ways most probably is "the highest good in most software development." At least that's how the story goes ;-) -- BradAppleton

As I understand it, the claim is that there is an objective standard of "beauty" (broadly speaking) which software ought to follow, and that code that follows it is objectively better than code that doesn't. I grant that this is possible, and it's important to know whether it's true, but I am doubtful. -- TomKreitzberg

The claim (by Alexander) in NOO certainly seems to be that there is an objective standard of beauty. I'm less certain that anything in NOO claims software ought to follow this. I have seen people urging software folks to explore the possibility however. -- BradAppleton

I share you doubts, Tom. I admit that beauty has a cultural dimension which transcends each human being, but, to me, it has also a personal dimension which depends on each personal history. Hence, as I see it, it cannot be defined as something fully objectivable. No more for architecture than (if it can make sense here) for software. -- JeanMichelAndre

Jean, you are giving the normal answer. ChristopherAlexander says that the normal answer is wrong. He gives evidence. He could be wrong, of course, but he is not just stating an opinion. The main description of the evidence that I have seen is in Dick Gabriel's PatternsOfSoftware. -- RalphJohnson

See also some of the writing of David Bus, an anthropologist quoted in one of Cope's "Geometry of Software" papers, whose studies produced a very provocative book back in the mid-80s suggesting that throughout all known cultures and history, the traits deemed aesthetically attractive in a mate seem less rooted in the "eye of the beholder" and more in the "survival of the fittest." Certain things, like being "romanesque" may have been seen as desirable in one culture, while being more fit/skinny were more desirable in others. But in all cases studied by the authors, those external characteristics were always seen as manifestations of the same underlying qualities. The way they were exhibited varied from culture to culture, but the things there were seen as indications of did not. Sort of takes the magic out of what some of us thought was romance as says it all comes from baser notions and needs of survival and adaptivity [sigh]. -- BradAppleton

software which is mostly driven by technical concerns -- TheTimelessWayOfBuilding is very much driven by technical concerns. Beauty comes when form fits function. The real world is bumpy, and the most efficient solutions are tailored to that bumpiness. Hence Alexander likes everything to be specialized; he doesn't go for much low-level reuse. He does go for reuse at higher levels. He has symmetries and recurring patterns. He seems to believe beauty involves the tension between high-level symmetry and low-level bumpiness.

In the carpets I think the bumpiness is partly arbitrary (although isn't it sometimes caused by mistakes in the weaving?). Although in that case form isn't necessarily following function, the reason we find it beautiful is that its appearance matches that of things for which form does follow function. So we can still learn something about beauty from carpets.

Much of this translates to software. We have high-level abstractions and low-level details, and often the details cause ripples at higher levels. Ideas present in concrete form at low level reappear in more general form at high level. We also see patterns and recurring themes across the board, as when superficially different problems are handled in similar ways because of a deeper similarity. So software can be beautiful too. Software which is close to the machine, and also close to users, and also close to programmers, will have most beauty. -- DaveHarris

I agree that software can be seen at different level of abstraction (e.g. instruction, function, class, component, system) and that "the details cause ripples at higher levels". But at any level, technical concerns and efficiency are the only parameters to take into account. From what I've read from Alexander's TheTimelessWayOfBuilding it is not the case in (his conception of) the architecture. Taking into account cultural habits (expressed as "patterns") is essential in the conception of successful buildings. I still don't see the equivalent in software, because the world where the users live (a 3D world) and the world where the programmer works (a not-bumpy editor window) are antithetical by nature.

One problem I see with the software culture pregnancy is that people are more and more urged to abandon their 3D, sensual world to adopt the 1D1/2, cold, disembodied, virtual world that software programmers (like me) are preparing to them. Maybe in a near future, users and programmers will share 'cultural habits' and the NatureOfOrder metaphor will gain a real meaning. Is it desirable ? -- JeanMichelAndre

I don't see people being asked to abandon any such thing. Consider it possible that maybe people are merely being asked to expand their perceptions rather than utterly of abandoning existing ones. -- BradAppleton

I'm sorry; I followed very little of that. I don't think of myself or my code as living in a text editor. It's more like a class or a method is a room I am sitting in, and the variables are furniture or tools in that place, and I need to get things done by using them or by walking into a different room to some other tools. It's not 3D, but it's not 1D either. Rather than cultural habits, I have common tools which I need to keep ready to hand for common jobs.

For me, one of the main features of software is that the abstraction is usually explicit. When you have several items with bits which are the same and bits which are different, an efficient and elegant design will usually represent the commonality and the variation explicitly, using templates and overloading, subclasses and dynamic polymorphism, routines with runtime parameters or whatever. For example, where Alexander would have a spiral pattern here and a spiral pattern there, two spirals, in software we might have just one spiral base class and two subclasses. Same idea, same theme of repetition with variation, but expressed directly in the code. Thus the real world can only aspire to the beauty of software.

Finally, I am not saying you should let your desire for beauty override your concern for efficiency etc. I'm saying that efficient code is beautiful. New programmers will learn to see this before they become expert. -- DaveHarris

Software does have a body, it's the virtuality: the conceptual structure, look and feel of using it. The "user interface," if you conceive of the user as a peripheral. Even when people are programming user interfaces, the "rooms" they live in are not the same rooms the users inhabit. We programmers live in the projection booth instead of the theater. We work on a machine that projects an image of a body, but the structures we focus on are the sprockets and light bulbs.

It doesn't have to be this way, it's not just the nature of computers or software, it's the way we have - or haven't - set things up for ourselves. It's the way our languages and programming environments work - or don't work. It's our view of programming and using as separate activities, and a whole industry and culture that backs up (or gives in to) that separation as if it made sense.

I believe the fact that our work occurs in a place so isolated from the user's experience contributes greatly to the bad quality of "user interfaces". Computers don't make sense to human beings, they don't make good use of humans' abilities at navigating, orienting, arranging. There are buttons and scroll bars on the screen, but that's not enough. A computer is not a fit place for a human to be. We haven't made it so.

In other words, the problem that Alexander is working against, that modern architecture is alienating because architects have lost a sense of or knack for what it's like to be in and using a building, occurs in spades in software. Like architects we have lost the connections between beauty, function and life; we've forgotten or retreated from their relevance to each other.

I agree with Dave Harris that "Beauty comes when form fits function," and that "Software which is close to the machine, and also close to users, and also close to programmers, will have most beauty." We are so far from that - software and the way we make it are so bad - that we can't even see how beauty would apply.

See SoftwarePatternsArentAlexanderPatterns.

-- SteveWitham

I once went to a lecture where the speaker was pleading the case for "elegance" in programming - as far as I was concerned, he was preaching to the converted (my mother was an artist, so maybe I picked up some of her attitudes). I believe that you guys might be interested in taking a look at FlowBasedProgramming from this point of view. In many ways I believe it resembles house- or bridge-building: It uses precoded, pretested components, about which knowledge and experience can be built up, but lets you build new ones; it is visual - it uses a network diagram as a fundamental, and necessary, mental construct; it seems to encourage application of real-world experience and metaphors; it is fundamentally asynchronous, like the real world; it is fractal or self-similar at many levels. I believe applications built this way can be more beautiful than ones built using synchronous, procedural, code, and are more maintainable, and tunable. Yes, it is possible to build ugly applications using it, but I believe appropriate, hands-on, education by an experienced, enthusiastic teacher, can prevent this to a large extent. Ugly programs using this technology are usually the result of trying to force it into a procedural mould - it has a natural asynchronism that makes some old-guard programmers very nervous! When you don't know exactly when things are going to happen, how can you reassure yourself that your application is running accurately? :-) But there are constraints that, when visualized clearly, can guarantee accuracy.

In my experience with it over almost 30 years, I have come to the conclusion that it can't be learned from a book (although I wrote one in 1994), but is best learned using something like an apprenticeship model. FlowBasedProgramming is a BodyOfPractice?, not a science, that you get good at by doing, but then so are most skills in the real world. Why should we expect programming to be any different? -- PaulMorrison

Software does not lack a body, and the body it 'has' is not ambiguous. The body of software is that of its victim, who is ignored or positively disadvantaged by the competitive advantage afforded its 'user' and 'sponsor' (or 'funder' etc.).

The most obvious example is the poor Iraqi bastard targeted by 'smart bombs' - the software has his body, then consumes it, then moves on to the next body. If it fails to kill that body, then it is 'fixed' to better consume other bodies.

See AllSoftwareHasVictims, BigSoupOfClasses