Excerpts From Christopher Alexander

Since these excerpts were intended to describe patterns in the architecture of physical structures, here are my two-cents on how they would or would not apply in the software domain.

"On no account place buildings in the places which are most beautiful. In fact, do the opposite. Consider the site and its buildings as a single living eco-system. Leave those areas that are the most precious, beautiful, comfortable, and healthy as they are, and build new structures in those parts of the site which are least pleasant now."

Does this mean we shouldn't put a piece of functionality on the best part of an existing platform because it might cover up its attractiveness? Is this principle suggesting the motto "If it's not broken, don't fix it" ? Don't agree this principle applies to software because if we're trying to cover up some classes, for example through the use of the façade pattern, then we're trying to simplify the overall functionality of the system. And this doesn't mean you can no longer use the covered up classes because we promote extensions in object-oriented design. In the case of buildings, once you cover up the best part of the land with a building, you pretty much can't take advantage of it. Now this principle does have a good reason for building on top of the worst part of a platform; it may force developers to refactor crappy code while adding functionality. The fact of the matter is that once a developer hacks some code together, we shouldn't expect it to get fixed anytime soon unless you have a disciplined team like the guys from Design Town who mark their "fudges". Many managers won't invest resources to refactor code that "already works".


"Unless the spaces in a building are arranged in a sequence which corresponds to their degrees of privateness, the visits made by strangers, friends, guests, clients, family will always be a little awkward"

Does this mean we should develop an application with the right degree of privacy levels or else it will be awkward to use/extend from? Well, encapsulation is supposed to provide us with this ability so that we don't change the state of a system through some unsafe method. In terms of actual usage, a user will certainly be annoyed if an application has unnecessary levels of privacy restrictions while a federal agent would feel insecure using an application that does not provide encryption.


"When they have a choice, people will always gravitate to those rooms which have light on two sides, and leave the rooms which are lit only from one side unused and empty". Software modules will be used if they're multiple channels for communicating with them but this may not actually be ideal.

Does this mean we should develop software modules that provide more than one way to communicate with it? If so, this definitely does not apply to software because you rather provide a single, consistent interface that would enforce communication integrity as described in ArchJava. Users would also prefer a single, consistent method for using a system. In software, simplification is king. The principle of adding more "windows" can make a system unnecessarily complicated.