The idea of thinking about architectural design as if one where doing operational research, i.e. applying the same kind of mathematical language, is a theoretically interesting idea. I also understand that the book was cult reading among software engineers for a period, but I doubt that many architects are following the method Alexander suggests when doing practical design. While the intensions are good, the output quickly becomes complex, as he illustrates through the examples towards the end of the book. The book is still interesting, however, but primarily as a way of understanding how architects think and how to apply this kind of thinking into other areas of practice.
This book is often recommended as a software architecture book. Of course software is never touched upon, and the author insists that it is the conclusions which he reaches that are important. What this book does very well is analyse the steps taken in reaching design conclusions. Even though these steps are not directly related to software architectures their lucidity instantly provokes a stream of software parallels. Final bonus point (which gets the 5th star) it's an easy read unlike those dry software patterns books - yawn.
This book outlines an approach to designing complex artifacts. A design problem is considered as a set of potential "misfits" between the artifact (or "form") and its context. Each misfit can be considered as a binary variable - either it occurs (1) or it doesn't (0). Thus the perfect resolution of a design problem consists in creating an artifact which sets all the misfits to zero. Unfortunately misfits tend to affect one another - modifying the design to resolve one frequently causes others to reoccur. For example, designing a vacuum cleaner with the best available materials makes it reliable and effective, but also expensive. Alexander considers design problems in terms of the couplings between misfits. Certain patterns of couplings will lead to problems which are practically insoluble, because solving one part of them "breaks" another part of the solution. Beyond a certain level of complexity it becomes impossible to manage all the interacting misfits. The answer, according to Alexander, is to consider the problem is such a way that misfits can be grouped into subsystems, effectively smaller problems which can be solved independently, then combined with other subsystems to solve the initial large problem. If like me you are a software engineer then this should all sound very familiar. This book contains the best explanation of what coupling is and why you want to avoid it that I have come across. It also serves as a foundation for Alexander's later, more famous work on design patterns. This is not a "how to" book - it doesn't describe a detailed design method or development process. However it gave me an invaluable insight into some of the issues underlying the design of any complex artifact, including software, and as such I would recommend it to all software engineers.