Christopher Alexander’s Patterns and Software Design (cont.)

Picking up where I left, I was about to say that in The Timeless Way of Building, Alexander says that “The details of a building cannot be made alive when they are made from modular parts.” Software is inherently modular, in the sense that it deals with abstractions, things that are distinct, so perhaps this is an indication of Alexander’s thinking not being fully applicable to software design.

But then again he may be referring to prefabricated modular parts and that building using them can’t produce living buildings. So software that is built in a more ad hoc fashion (note that that’s not necessarily something bad) might correlate to Alexander’s ideas. And indeed, Alexander goes on to describe a process which I think has great relevance for software design.

He speaks of when building a house, that you should first build it the rough, after having established its pattern language, and then apply piecemeal acts of repair to evolve it into something more coherent and complex. For software, this would mean building a rough first version, which covers the entire problem domain, but without the details, and then adding small pieces of functionality, and doing continuous refactoring. (Richard P. Gabriel has talked about repair in the context of software, for instance in Mob Software. And I think that Alexander’s ideas must have influenced XP.)

Alexander continues:

The details of a building cannot be alive when they are specified in the form of working drawings, because these drawings always assume, for the sake of simplicity, that the various manifestations of a given part are all identical.

The person who draws a working drawing cannot draw each window, or each brick, differently, because he has no basis for knowing the subtle differences which will be required. These only become clear when the actual building process is already under way.

For software, it’s very hard to anticipate the subtle details of each required piece of functionality. The only sure way is building something and testing it in the real context.

(I see now that I’ve written the following in the margin on page 335, “intentional programming closer to Alexander’s patterns than [software] design patterns?” I can’t remember what I referred to. See my two posts on intentional programming.)