Notes On The Synthesis Of Form

""Notes On the Synthesis of Form " by ChristopherAlexander

ISBN 0674627512 Early book in the development of patterns (Alexander's dissertation, I believe). Has several compelling lessons for software development, and still (though the details and concrete instantiations of patterns were yet to come) proves invaluable as background and rationale. Reading this made me ask IsXpAnUnselfconsciousProcess.

-- DavidHarvey

Design is the process of resolving conflicting constraints. The absolute best explanation for why evolutionary is better than heroic design is the book NotesOnTheSynthesisOfForm by ChristopherAlexander.

To cast what that book says into programming terms, consider a tall stack of conflicting requirements. Suppose programmer A took the whole stack, read each one, selected the most-conflicting requirements as a subset, and "thought about" how to design such that the majority of the conflicts went away. Then programmer A commits this design to source code, and then starts adding all the minor requirements to that design - the ones A assumed did not conflict.

Now suppose programmer B sorts the requirements into a random order, then pops a requirement off the top of the stack and writes the >simplest< possible design that could satisfy that requirement. Then B pops the next requirement, and makes the simplest possible change to that design to accommodate this requirement. Then B reviews the entire project to ensure that it is as simple as it can be for the current set of committed requirements. B removes any duplication found at this point. Then B repeats the process for each feature in the stack.

Years of research and practice have shown many people that programmer A adopted the correct technique. Programmer A deferred risk by taking a "most risk first" approach.

But the first technique is, in fact, deceptive. It adds risk. Programmer A took a flying leap all the way from no design to a very big design with lots of parts. B, however, took the design incrementally from nothing up a slope of minimum possible complexity. If programmer A leapt too far, the "extra design" that now burdens the project is hidden and terribly difficult to find and take out.

Further, we live in the real world, where "stakeholders" need to know we are not burning up their money. A's technique ran "invisible" for a long time, with no >accurate< way for a stakeholder to unobtrusively inspect any intermediate product.

Programmer B can get the current feature set reviewed at any time. Short iterations. If the project is in trouble, the stakeholder knows in less than 2 weeks, not in more than 2 months. Further, because programmer B needs the requirements list prioritized, the stakeholder can assign the risk to business value order.

That is the secret behind this evolutionary methodology:

BusinessValueOrientedProgramming

-- PhlIp

I recently read the book for the first time. It has two parts. The first part is a very good analysis of why design is so hard. The second part is a proposed methodology. Alexander says that it is NOT a methodology, but I know one when I see one. Anyway, I bet that the reason that he does not like the book is because of the second part. But it was probably better than the average software methodology. The first part is definitely worth reading, and the second part is interesting to those who are curious. -- RalphJohnson

I'm struck by the resemblance between the rule of CouplingAndCohesion and Alexander's formal treatment of the "main" problem of design - hierarchical decomposition of the set M of misfit variables (the "things which might possibly break") into subsets which

maximize the connections between their components (high cohesion) but also
are minimally connected with each other (low coupling)

In other words, the issue of CouplingAndCohesion isn't just central to software design - it is central to all design, if Alexander is to be believed.

ConstantineAndYourdon? made reference to Alexander in their 1978 Structured Design, so it is likely that Constantine's ideas of CouplingAndCohesion were influenced by Alexander's work.

: (p. 104) ... Attempts have been made to quantify the strength of various types of coupling.* ...
: *See, for example, Glenford J. Meyers, Reliable Software through Composite Design (1975) or Christopher Alexander, Notes on the Synthesis of Form (1971 [sic])

It has changed my way of thinking about design; and stopped me struggling to find a Perfect Design. Alexander cleanly and convincingly presents that Good Design is the absence of Bad Design, and once you understand that, all those BDUF meetings seem an achingly pointless waste of time.

Several of the summaries here, notably the first one, are inaccurate. Alexander's work is, roughly speaking, a natural philosophy of design. His treatment of "self-conscious" design: the problem of figuring out what the problem is, has a lot of structural similarities with Dave Parnas' "On the Criteria to Be Used in Decomposing Systems into Modules".

CategoryBook