Talk:Notes on the Synthesis of Form

From Wikipedia, the free encyclopedia

I got my first copy of "Notes on the Synthesis of Form" in the early 70s, and immediately understood the potential of the Alexander's approach as a general purpose design strategy, suitable of being applied to any field. Since then, I have been using some of his core ideas in different non-form and non-physical related problems (software engineering, resources allocation, organization, project management, etc.), where the key management device is always the minimum flow intra-components principle. Over the time, I have developed some tools to implement part of the mathematical apparatus described in the book; mainly, those pieces to deal with the splitting process. However, there is a major aspect related to the constructiveness of the approach, (constructiveness is in fact the cornerstone of the Alexander’s method). To my understanding, after realizing the intrinsic difficulty involved in the mathematical and computational apparatus of his amazing approach, Alexander just reduced the constructiveness problem to his methodology of patterns. Patterns seem to me nothing but visual approximations to something much more powerful, which not necessarily can (or need to) be translated into graphical forms.

In fact, constructiveness seems to be an extremely powerful device, which, for example, has already been implemented on software engineering through formal grammars. Formal grammars, for instance, are a paradigmatic example of constructiveness and constructive tools; they are at the same time, both, the solution to the problem of describing a given language and the solution to the implementation of the correlated translator, interpreter or compiler. So, once you have described the problem you have also got the solution; provided you have a meta-compiler available. This can be also applied to any system of software, whatever its structure could be. Thereafter, any cybernetic system described, for example, by, Petri Nets would be, at the same time the expression of the problem and its correlated solution. And so on.

Another very good example of this is the metaphor about the magnetic field in the book, which I mentioned in the article; there, the equations describing the magnetic field might be properly called an abstract pattern. Other examples of abstract patterns can be found in problems related to social sciences, physics, and other fields. An abstract pattern like f´(x) = (sign)* k* f(x) describes the rate of change of the function f(x) as being k-proportional to the value of the function, and it represents, among many others, the following non physical processes, which, for the most, cannot be easily translated into graphical patterns:

• Growth of resistance against change within a group,
• Growth of a certain population,
• Degradation of IT service throughout time,
• Degradation of data quality throughout time,
• Tension among members of a group working under stress.

A problem involving the issues above would be represented by the union of some slight variations of that core abstract pattern f´(x) = (sign)* k* f(x), and that union would provide a well founded description of the problem embodied by the related subset of requirements along with their inter-dependences, while giving a workable description of the solution. Therefore the quest for such an abstract pattern with f´(x) = (sign)* k* f(x) as the kernel should be the reference in the search for constructiveness.

I would appreciate any valuable thoughts on this.