Christopher Alexander is a noted traditional (i.e., not software) architect who's been writing about design since well before I was born. Some of his books, most notably A Pattern Language, are the basis of the patterns movement (for lack of a better word) in the software industry. Anyone who writes on software patterns includes his works in their bibliographies, so I figured there must be something to it.
Not being one to trust others' reductions and paraphrasing any more than I have to, I've been wanting to dig into his work myself for some time. I finally got around to it in early March. I've started with Notes on the Synthesis of Form, which seems to be the first book in the series on patterns.
Apart from loving the plain black cover and white block lettering and of course the obscure sounding title, I also enjoyed the innards. It really is interesting how similar the problems and processes of three-dimensional design and architecture are with those of software design and architecture.
I dare not reduce this work or ask you to depend upon my fuzzy recollections for a precise summary, but what follows is what I recall of the book, those things which made enough of an impression to stick with me at least these few weeks since my reading.
First, I recall the observation that we often only really know the proper form (solution) by recognizing things that are out of place (misfits). What's interesting about this is how utterly incompatible this is with the idea of waterfall design, i.e., trying to imagine and gather all the requirements of a solution up front. We simply lack the imagination to create solutions that fit perfectly using the waterfall approach, and the more complex the problem, the more likely this approach is to fail.
This is in part why agile, iterative development and prototyping works better. It enables us to create a form (a solution) and see how well it fits against the actual problem. We can easily recognize the misfits then by comparing the prototype or iteration to the problem and make small adjustments to eliminate the misfits, ultimately synthesizing a much better-fitting form than we could ever imagine up front.
Second, I found the approach to the composition of the individual problems into the most autonomous groups (problem sets) possible to be insightful. But the key observation here is that this composition should be based in the realities of the problems, not in the preconceived groupings that our profession has set out for us.
For instance, rather than starting with the buckets of security, logging, exception handling, etc., you identify the actual individual problems that are in the problem domain, group them by their relative interconnectedness, and then attempt to design solutions for those groupings. The value in this observation lies in keeping us focused on the specifics of the problem at hand rather than attempting to use a sort of one-size-fits-all approach to solving design problems.
Further, if we take this approach, we will have more success in creating a form that fits because the groupings are along natural boundaries (i.e., areas of minimal connectedness) in the problem domain. Thus when we create a solution for a set of problems, the chance that the solution will cause misfits in other sets is diminished.
Finally, as we identify these natural sets in the problem domains, we see recurring, like solutions (patterns) emerge that can be generalized to create a sort of rough blueprint for solving those sets of problems. The patterns are not rote algorithms with no variation or creativity but rather are like an outline from which the author can craft the message using his or her particular genius.
This avoids the pitfall of the one-size-fits-all solution, provides for competition and creativity, and ultimately has the best chance of enabling designers to create a system of forms that integrate harmoniously and address the actual problems at hand.
And the idea is that these sets are also hierarchical in nature such that one can create sets of sets of problems (and corresponding patterns) to create higher and higher level coherent views of extremely complex problem domains. This, of course, fits nicely with the way we deal with problems in the software world as well (or in managing people, for that matter), dealing with problem sets and patterns all the way from enterprise application integration down to patterns governing individual instructions to a CPU (or from the C-level management team down to the team supervisors). What can we say, hierarchies are convenient ways for us to handle complex problems in coherent ways.
So what does it all mean? Well, I think it in large part validates recent developments in the industry. From agile development (including test-driven design) to domain-driven design to, of course, the patterns movement itself. We're seeing the gradual popular realization of the principles discussed in this book.
It means that if we continue to explore other, more mature professions, we might just save ourselves a lot of trouble and money by learning from their mistakes and their contributions to human knowledge. It's like avoiding a higher-level Not Invented Here Syndrome, which has long-plagued our industry. We're a bunch of smart people, but that doesn't mean we have to solve every problem, again! Why not focus on the problems that have yet to be solved? It makes no more sense for a developer to create his own custom grid control than it does for our industry to try to rediscover the nature of designing solutions to complex problems.
It also means that we have a lot of work to do yet in terms of discovering, cataloguing, and actually using patterns at all levels of software design, not for the sake of using patterns but, again, for the sake of focusing on problems that have yet to be solved. I look forward to continuing reading The Timeless Way of Building and to the continued improvements of our profession.
The opinions expressed herein are solely my own personal opinions, founded or unfounded, rational or not, and you can quote me on that.
Thanks to the good folks at dasBlog!
Copyright © 2017 J. Ambrose Little