A Field Guide to Boxology

I'll be interested to hear the discussion around this paper in tomorrow's lecture, because I'm not sure what I was supposed to take away from it. The first three sections seemed like a crescendo up to a set of tables that I expected to be incredibly rich...but that fell flat on their face for me. Like 慈 said in a previous post, it was like reading a dictionary. It just came of as a list of facts. The fact that a "Heartbeat" style has a hierarchical control issue topology whereas the "client/server request/reply" style uses a "star" topology doesn't seem to give me any insight or have any room for a controversial interpretation, but the information may be useful in the future as a reference. Section 4 did try to give a little more insight and context to the styles, but it still came off as information better suited for flash cards than analysis.

Software Architecture in Practice: Chapter 4

My main takeaway from this chapter is that I'd really like to read chapter 5. As mentioned in my previous post, real-world, practical examples are important to me. I've seen plenty of checklists of quality/non-functional requirements before and grids showing which quality attributes must be sacrificed when another needs to be emphasized. What really interests me is *how* do I make my system more modifiable.

That said, I do find the "Portion of Scenario/Possible Values" tables associated with each quality attribute to be useful. I feel that the authors did a good job of breaking the scenario into steps and providing possible values in a way that is practical, not overly academic. I often get frustrated with literature that feels too academic & disconnected from real-world software development projects. (My subscription to IEEE's Transactions on Software Engineering was a waste of money, whereas IEEE Software is filled with useful nuggets usually based off of case studies.)

I also liked how the authors gave examples of how usability often is an architectural concern & not just something that the front-end designers have to prototype & tinker with. I likely wouldn't have put cancel & undo functionality in this bucket and may have skipped over functionality like that in future planning discussions.

I'd like to give another shout out to Fredrik Kjolstad for his explanation of the difference in connotation of quality vs. non-functional requirements. As he said, "...one would be less inclined to write programs that are without quality attributes than programs without non-functionality." [http://fredrikbk.blogspot.com/2009/08/software-architecture-in-practice.html]

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.