Beautiful Architecture: Thoughts on Foreward & Chapter 1

As expected, the first chapter of this book contained high-level, overly complicated thoughts on "what is software architecture?". As a result, I actually found the forward to contain more interesting ideas.

A few of the universal principals listed in the forward that struck me for one reason or another were:

• Minimize mechanisms: This boils down to not needing "the best" solution to every problem, simply one that meets all the necessary requirements and fits well with the existing architecture. This reminds me of the key lesson I took away from "The Paradox of Choice" by Barry Schwartz: if you find something that meets all of your expectations, then there is no need to continue looking for something better. That is not to say that your expectations can't be extremely high. The idea is to save yourself the time and frustration that will be brought on by looking for something better when you've already found something good enough. When applied to software, you can prevent your system from becoming overcomplicated and over-engineered by using a more simple solution that meets all of your needs rather than "the best" solution. On a recent project to develop an intranet web application used by less than one-hundred users in the same time zone, a developer was making an argument for doing things a certain extremely complicated and expensive way because it would get us closer to the awe-inspiring five nines of up time. He neglected to consider that the application only needed to be up for roughly nine hours per day, five days per week!
• Construct engines: This concept is still a little vague for me, and I wish I could find the Ivar Jacobson literature being referred to. This principal stood out to me because it calls out "bas[ing] your architecture on use cases and one function at a time (i.e., use 'controller' objects)' as a source of brittle systems. Unfortunately, too many of the applications that I have worked on in my two years as a professional developer have followed this anti-pattern, much to my chagrin. I know that I don't like it, but I'm not quite sure how to make the specific applications better. I know at a conceptual level how I would like to re-work these systems, but I need some more examples to study to become a "doer" and not just a "thinker." Hopefully chapters two through fourteen of this book will provide those real-world, concrete examples.
• Resist entropy: I had to come back and bookmark this one after reading chapter one. Chapter one tries to create analogs to software architects using examples from other industries. However, I feel that resisting entropy is a key differentiation between software architecture and all the rest. It is very important yet very difficult to create an architecture that will allow future developers and architects to easily fall into the pit of success, to paraphrase Martin Fowler, rather than have to work to keep the system beautiful. I feel that it is much easier for the architect of a building to predict what limited entropy his construction will endure.

I loved Mellor's summary of how to become a beautiful architect: "That way is never to believe that the last system you built is the only way to build systems, and to seek out many examples of different ways of solving the same type of problem." As the name of my blog indicates, my philosophy is that if you ever lose your thirst for knowledge and self improvement, you stop truly living an exciting and enjoyable life and just start coasting through it.

Now as for chapter one, I basically thought it was a typical intro to any architecture book and lacked many interesting insights.

I agree with 慈's post on August 27th that stated, besides his love for diet A&W root beer, that the author's seem to have gotten their steps out of order based both on traditional processes, which should always be challenged whenever possible, and the logical reasoning that he and I have, which is likely based on a dramatically smaller set of experiences than those of the authors. The functional requirements often drive the quality/non-functional (I like Fredrik Kjolstad's differentiation of the two seemingly synonymous terms). I have found in my experiences that the stakeholders often dramatically overestimate their need for certain quality requirements, and it is the examination of the functional requirements that gives me and my team a better handle on realistic expectations for quality requirements.

I am interested to see what, if anything, other readers found useful from the "Architectural Structures" section of the chapter. I found it to be an overcomplicated explanation of rather simple concepts, what I often fear that I will find whenever I read a book on architecture and what I really hope will not be a consistent pattern throughout the rest of the book.

What I took away the most from this chapter is that I really need to get "Software Architcure in Practice" and "The Mythical Man Month" by Fred Brooks off my reading list and into my hands. I could not more strongly agree with Fred Brooks's that the need to maintain "conceptual integrity," or consistency as I read it, in the application will often trump the desire to put in a "better" way of solving a problem.