Table of Contents

Quintero, F. M. Software that has the Quality Without A Name. 2011


(This article contains the author's thought and is not structured as a research paper. Hence, the following is a paragraph taken from the article but not its actual abstract; the article does not have one.)

So you can see the essence of design patterns: good, tested recipes that don't constrain your implementation in unnecessary ways. The patterns do not mandate a particular style, nor include superfluous decorations: the book doesn't tell you, “make this shape of flourishes in the handrails”; instead it tells you, “a house should have its rooms placed such that sunlight enters them according to the time of the day in which they are most used - East for the bedrooms in the morning, West for the living room in the afternoon”.


Yann-Gaël Guéhéneuc, 2014/05/16

This article describes the author's progress from casual observer to expert in design patterns through learning and using real-world architectural patterns. The author start by stating that he used to dismiss refactorings and design patterns as “nothing that you could not discover yourself”. Then, while renovating/expanding his house, he started studying Alexander's patterns and “became tremendously interested in [Alexander's work]”. He realised that the patterns “do not mandate a particular style, nor include superfluous decorations” and they are an “approach [to] design” with “good solutions […] that wouldn't constraint [the] implementation unnecessarily”. Moreover, the patterns “give […] a vocabulary to talk about how things are constructed”.

From then on, the author introduces the idea of “Quality without a name”: “[a] thing or place has the quality without a name if it is comfortable, has evolved over time in its own terms, is free of inner contradictions, doesn't try to draw attention to itself, and seems to have archetypal qualities”. Things that have the quality without a name seem to have 15 properties in common, according to Alexander's work. The author summarises these 15 properties:

The author goes on with Alexander's idea of transformations, which preserve the structure of the things, as refactorings preserve the behaviour of a software program. He then gives an example by Richard Gabriel to transform a PhoneCall class to create two strong centers, then extract the latent center in the middle, and then reach a design where multi-way calls, conference calls, can happen.

The author summarises the fundamental process to apply structure-preserving transformations:

  1. Start with what you have - an empty lot, or an already-built building, or a program that looks ugly and is hard to use.
  2. Identify the centers that exist in that space. Find the weakest center or the least coherent.
  3. See how to apply one or more of the fifteen structure-preserving transformations to strengthen that weak center. Does it need to be delimited? Does it need to be blended with its surroundings? Does it need more detail? Does it need to be de-cluttered?
  4. Find the new centers that are born when you apply the transformation to the old center. Does the new combination make things stronger? Prettier? More functional?
  5. Ensure that you did the simplest possible thing.
  6. Go back to the beginning for the next step.

The author recalls that Alexander does not like destroying things to build new ones. Similarly, we should refactor code rather than scrap it. Also, Alexander does not like detailed, up-front design because “you cannot predict absolutely everything that will come up during construction or implementation”. Instead, we must “continually evaluate what [we create] against real users and real use cases”. Finally, the author concludes that “Quality without a name” is really a (mysterious) synonym to “living structure”, i.e., things “that are build according to that method”.

This article is interesting because it put Alexander's consequent work into perspective and summarises Alexander's main ideas and finding. It also relates real-world architecture with software design and makes a good case for reading books about refactorings and design patterns.