Here are quotes from the article The Road, Christopher Alexander, and Good Software Design by Linda Rising (I can’t remember where I picked up the link, so forgive me for not giving credit):

[Christopher Alexander] is describing living structure as being able to grow in the face of unpredictable events. That sounds like changing requirements to me! His search for wholeness [one of the expressions he uses to refer to “the quality without a name”] is obviously a meaningful goal for software.

Rising mentions several research experiments of hers, of which several involved two versions of an Ada program, representing good and bad designs according to her metric for measuring information hiding – and the test subjects were told to make specific modifications to the programs given to them. Of one such experiment, she writes:

[T]he good programs showed that the modification was performed but nothing else was touched. In the bad versions, many other changes were made, in addition to the required modification.

[…] I felt that the students were reacting to something in the good program. They saw that it was good – and they left it alone. They saw the bad program and felt compelled to improve it.

Here she quotes Richard Gabriel about “software habitability” – and this can probably be found in his book Patterns of Software: Tales from the Software Community: “Habitability is one of the most important characteristics of software. It enables developers to live comfortably in and repair or modify code and design.” (I guess that Gabriel’s original writing has better punctuation than this, though.)

Back to Rising’s article: She talks about an early experience as a programmer, when she tried to understand an Ada program she was supposed to maintain. She was surprised that she understood it so quickly, and wondered if this had to do with it being written in Ada. Later, as she did these experiments, she applied her information hiding metric to this program, and it got low scores when applied to individual modules. She continues:

But when the behavior of the entire program was examined, each module was treated by the rest as though it were perfect. Even though some interfaces were not minimal, for instance, the program never took advantage of that and instead played by the rules, refusing to touch global data or violate information hiding. This isn’t a good way to design, of course, it leaves the program open to maintainers who might decide it’s easier to break the rules – since it is possible to do so […]

Again, she quotes Richard Gabriel in Patterns of Software (seems to be a must-read), talking about software that possesses the quality without a name:

Its modules and abstractions are not too big [some punctuation is missing here] if they were too big, their size and inflexibility would have created forces that would overgovern the overall structure of the software; every module, function, class, and abstraction is small and named so that I know what it is without looking at its implementation.

If I look at any small part of it, I can see what is going on, I don’t need to refer to other parts to understand what something is doing. This tells me that the abstractions make sense for themselves – they are whole.

If I look at any large part in overview, I can see what is going on, I don’t need to know all the details to get it.

Everything about it seems familiar.

I can imagine changing it, adding some functionality.

I am not afraid of it, I will remember it.

I’ve been thinking about this in terms of code suggesting things about its enviroment, so to speak. I tried to express this in this post, but I don’t know whether I succeeded. So it’s nice to find things about this.

Rising ends her article with this account of coming out from Christopher Alexander’s keynote at OOPSLA ‘96 (the keynote transcript can be found here):

We walked thoughtfully out of the ballroom, down the hall to the book displays. I stood in line for an autograph. When I finally reached the head of the line, I told Alexander my story and asked him if the students who left the good programs unchanged were perhaps responding to a feeling of wholeness in the design. He smiled broadly and said, “I like it!” He could understand both the engineering compulsion to make improvements and the reaction of a designer to something good, the developer’s decision to leave it alone. Maybe building architecture and software architecture do share some measurable qualities of wholeness. Maybe they can both have the quality without a name. I’d like to think so.