Problem Solution

Problem = Solution

In Notes on the Synthesis of Form (Harvard University Press, 1964), Christopher Alexander argues that every design problem begins with an effort to achieve fitness between two entities: the form in question and its context. The form is the solution to the problem; the context defines the problem. As an example of fitness, Alexander points to the task of making a metal face smooth and level. A standard block, smooth and level to a precision greater than required by the target metal face, is inked and rubbed against the target. The presence or absence of ink on the target indicates high and low spots that need to be reground. The standard block is the context, the target face is the solution, and it is clear how the standard defines the target.

I ll develop the second point more fully in the next chapter, but again, here s a small preview. In their discussion of the principle of modular software design, Witt, Baker, and Merritt ^[6] quote Plato and Christopher Alexander (emphasis added):

[First,] perceiving and bringing together under one Idea the scattered particulars, so that one makes clear the particular thing which he wishes [to do] [Second,] the separation of the Idea into classes, by dividing it where the natural joints are, and not trying to break any part, after the manner of a bad carver I love these processes of division and bringing together and if I think any other man is able to see things that can naturally be collected into one and divided into many, him will I follow as if he were a god.

” ”Plato, circa 400 B.C.

In practice problems are not homogenous. They are full of knots and crevices which exhibit a well-defined structure. An analytic process fails only if it does not take this structure into account.

” ”Christopher Alexander, 1964

In these quotes, Plato and Alexander ”and Parnas, ^[7] Brooks, ^[8] and Alexander ^[9] again, in other contexts ”are talking about the notions of coupling and cohesion, familiar terms to any software developer. However, they re not talking about the structure of a computer program; they re talking about finding the naturally occurring divisions and classifications ( natural joints ) in the problem space. This is an essential difference because the naturally occurring modules in a problem space are not isomorphic (exhibiting fitness between context and solution) with the modules discovered and defined when you are thinking about the design of a computer program.

But they can be. Thinking like an object will lead to a greater degree of isomorphism between objects found in the problem space (the enterprise domain) and those employed in a solution space (the computer program) than thinking like a computer. Isomorphism of the modules (objects) in problem and solution space is a desirable, in fact essential, quality for software. I ll demonstrate the validity of these assertions in the coming pages.

Behind the Quotes ”Christopher Alexander

Christopher Alexander is an architect. Not a software architect; rather, the kind who designs buildings and cities. For an outsider, he has significantly affected the practice of software development. I ll cite the work and ideas of Alexander frequently in this book as well as add biographical and background information in later sidebars.

Alexander first came to the attention of the software community in 1968. He was frequently cited in papers at the NATO-sponsored first conference on software engineering; that conference marked the widespread adoption of software engineering as an appropriate metaphor for development. The ideas on design and formal process that he articulated in Notes on the Synthesis of Form were cited as appropriate for emulation by budding software engineers . Many years later, his work on architectural design patterns in A Pattern Language: Towns, Buildings, Construction (Oxford University Press, 1977) inspired the software patterns movement of the past decade .

Although most followers of Alexander s ideas, and Alexander himself, believe the software community missed the real essence of his ideas and settled for simply copying a syntactic form, his influence is undeniable.

 

^[6] Witt, Bernard I., F. Terry Baker, and Everett W. Merritt. Software Architecture and Design: Principles, Models, and Methods . New York: Van Nostrand Reinhold. 1994. ISBN 0-442-01556-9.

^[7] Parnas, D.L. "On the Criteria to Be Used in Decomposing Systems into Modules," Communications of the ACM , Vol. 15, No. 12, pp. 1053 “1058, December 1972.

^[8] Brooks, Fred. No silver bullet, essence and accidents of software engineering, Computer Magazine , April 1987.

^[9] Alexander, Christopher, Sara Ishikawa, and Murray Silverstein. A Pattern Language . Oxford University Press. 1977.