> The problem Alexander is trying to solve is: > How can you distribute responsibility for design through all levels of a large hierarchy, while still maintaini

> The problem Alexander is trying to solve is: > How can you distribute responsibility for design through all levels of a large hierarchy, while still maintaining consistency and harmony of overall design? > The pattern language does not tell you how to design anything > It helps you decide what should be designed > You get to make up whatever patterns you think will lead to good designs I'm not sure I completely agree with this. I agree Alexander was trying to establish a vocabulary for communicating common ideas, and I agree that his collection of patterns wasn't meant to be the one true canonical list of architecture patterns, but I do think a lot of his patterns do specifically tell you how to design things. Also much of what he wrote isn't specific to large construction projects with many stakeholders ("The Oregon Experiment", which I haven't read, is an account of the process of designing the University of Oregon campus. However, "A Pattern Language" would also be of use to a person designing their own house by themself.) What makes A Pattern Language more interesting and intellectually honest than just a list of design rules is that he gives justifications for each pattern and tells you what problem they solve and why he believes them to be an optimal solution. Anyone else can come along and propose a better pattern that solves that problem (or a more general one) in a better way, or can provide some argument that the problem isn't really a problem in certain circumstances. There's no appeal to authority or tradition; patterns are judged solely on their merits (to the extent that we can understand what those are; architecture is strongly tied to psychology, which isn't entirely understood). (I really wish that someone would write a book similar to A Pattern Language, but about music theory.)