Armstrong Thesis (Chapter 6)

Last night I finished reading Chapter 6 of Joe Armstrong's thesis on building fault-taulerant software. The chapter was primarlily about putting together alot of what we have learned into some concrete examples. The chapter showed code relating to the various behaviours and supervision models that we had learned about previously. I have to say that I am a big fan of examples. I think they help to solidify my understanding of the material.

Chapter 6 is the last chapter that we will be reading in CS 527. Having about 12 years of industry experience under my belt, I can't help but think about why I had never heard of Erlang before. Is it because I have worked primarily on projects dealing with standard line of business type apps in companies whose core businesses were not technology related? Hmm.

I also wonder about the adaptability of these concepts to other langauges. Could the concepts such as supervision trees that are first class citizens be adapted to a language like C# and maintain the same sort of effect?

Pipeline, Geometric Decomposition, Data Parallelism

Three of the readings for tomorrow's class are on parallel algorithm strategy patterns. We discussed a few of these in yesterday's class as well. The three for discussion tomorrow are the pipeline, geometric decomposition and data parallelism patterns.

The pipeline pattern is probably the pattern that I had heard/read the most about previously. This pattern is as you would expect; stages of the pipeline are executed concurrently to exploit the parallelism present.

The geometric decomposition pattern breaks the input problem space/data structure into chunks and processes the chunks in parallel. Some of the concerns with this pattern are in regards to chunk granularity and data dependencies between chunks.

The data parallelism pattern writeup could us a bit more detail :). Data parallelism exploits situations where the same computation is performed on different input data. These computations can then run concurrently.

Having read numerous parallel patterns over the past few weeks, I think I have done myself a bit of a disservice by not having programmed on any large scale parallel systems. I think having some real world experience in this area would go a long way with understanding these patterns.

Armstrong Thesis (Chapter 5)

In Chapter 5 of Joe Armstrong's thesis, we are introduced to programming fault tolerant systems. Joe begins the chapter discussing the concept of falling back to simpler tasks if what ideally should be done cannot. The idea is that simpler tasks mean simpler code and in theory should be able to succeed even when the more complex tasks cannot. I think Erlang works well with this sort of methodology. Attempting to do this type of fallback in other languages such as C/C++/Java/C# is not always as straightforward as it could be.

Joe also discusses the concept of supervisors in more detail. We were introduced to them in earlier chapters, but in this chapter we began to dig in a little deeper and look at AND vs. OR supervisors. Child tasks monitored by AND supervisors are always restarted together. The premise being that the tasks work in conjunction so if one fails they should all fail. The tasks for OR supervisors are handled independently.

The chapter concludes with discussion on what exactly constitues an error. In my view, an error is essentially any type of problem that was unaccounted for in the code. I think Joe's definition is much more poetic, but in the end I think our philosophy is essentially the same. Again, another good read. On to chapter 6...

Task Parallelism, Recursive Splitting, Discrete Event

Part of today's class discussions will be about the three patterns identified in the title of this post. These patterns fall into the parallel algorithm strategy class of patterns. Essentially, the patterns address issues on how we exploit parallelism to better solve the problem at hand.

Being somewhat new to the world of parallel patterns, I was able to get a basic understanding of the discussion points of each pattern and the rationale behind them. I will say though that as the number of patterns that we read increases, it is sometimes more unclear as to how certain patterns are differentiated from others. I am hoping the discussion in class will be lively and I will pick up a deeper understanding of each of these three patterns.

Armstrong Thesis (Chapter 4)

For the last class, we read chapter 2 of Joe Armstrong's thesis. Today we will be discussing chapter 4. (Note: Chapter 3 which was skipped was all about the Erlang language syntax ... I skimmed it over, but after reading Chapter 4 it is obvious that I really need to go back and read Chapter 3 in more detail)

In Chapter 4, Joe introduces us to a couple of concepts. Specifically, the chapter discusses some high level concepts for programming with Erlang such as keeping concurrent and sequential code as separate processes, the overall ideology behind error handling and the concept of letting a process die on error while another process monitors for errors (workers/supervisors).

The chapter wraps up with a brief discussion on intentional programming. I thought this discussion, albeit brief, was interesting. The general concept is that your code should be easily understood and one of the examples given was about a lookup method which could be used in three different contexts, depending on the developer's intent. Armstrong points out that a better approach would be to make this three separate methods. That way it is clear what was meant by the calling function. I think there is definitely some merit to this approach and I really don't think it is specific to Erlang.

As time permits, I would like to write a program using Erlang. I like the ideas we've seen so far and find it interesting. Any ideas for a good project to get started?

Dense Linear Algebra, Graph Algorithms, Monte Carlo

No, contrary to how the title sounds, I am not moving to Vegas with some surefire "get-rich-quick" gambling scheme. For one of this week's CS527 lectures we have moved our discussions from structural patterns to computational patterns. The items in the title are all computational patterns for parallel programming.

Having done very little programming (with emphasis on the very little part) for large parallel systems these patterns were new to me. The patterns made sense and after reading them I think they were clearly documented. I particularly liked reading about the trade-offs and forces in play such as data movement costs vs. computation time for the dense linear algebra pattern, data structure choices for graph algorithms and threading/SIMD allocation in monte carlo simulations.

Hopefully in tonight's discussion there will be students who have work with these patterns. I look forward to hearing about their experiences.

Armstrong Thesis (Chapter 2)

As part of the reading list for CS527 this semester, our class has recently began reading the thesis of Joe Armstrong. The thesis is about building reliable software assuming that there will be hardware and/or software errors present.

For this week's reading we focused on Chapter 2 which introduces the architectural model being proposed. The chapter begins by introducing the original problem domain (telecom switching systems requiring essentially 24/7 operation with the ability to be updated while running). Oh wait ... did I mention that we are also going to assume that there will be hardware & software errors and that the system has to be able to work around such issues? Not an easy task!

Armstrong approaches the problem through the use of what he calls "concurrency oriented programming languages" (COPLs). COPLs typcially consist of and must support the concept of processes to serve as isolation boundaries. Communication between processes is achieved through message passing. Message delivery is guaranteed in-order between two endpoints, but is not guaranteed reliable. The other key feature is that processes must be able to detect failures of other processes and react accordingly. Armstrong introduces the Erlang language as one such implementation.

The remainder of the chapter discusses library support of Erlang for things like stable storage (storage that survives a crash) and various behaviours that assist with building these systems.

In subsequent weeks we will be reading additional chapters from Armstrong's thesis. If chapter 2 is any indication, this seems like it will be a good read.

"Event-Based" and "Map-Reduce" Pattern

Two patterns we will be discussing in class tomorrow are "event-based, implicit invocation" and "map-reduce". The event-based pattern is a little light on details, but is straightforward enough. In this pattern, there are:

• components acting as announcers (posters of events) and/or listeners (subscriber of events)
• a medium which acts as communication fabric hooking together announcers and listeners

With this pattern, one of the keys is that announcers are not aware of which listeners (if any) are present. This combined with the asynchronous nature of the system makes for a great architecture. However, I think that implementing the "medium" is a non-trivial task that is somewhat glossed over.

The other pattern, map-reduce, is another fairly simple pattern. The concept is that you have a map function that can be applied concurrently to all objects in a given set and then the results of each operation are reduced through a reduction function. This is an excellent pattern for problem domains that fit as the only thing that really has to be done is the creation of the map function and the reduction function. I would be interested to see some actual implementations of this pattern and see how well they scale as object counts increase. In naive implementations, I think there could be some potential lock contention scalability issues with the task queue and repository perhaps?

Refactoring for Reentrancy

One of the readings for today's class, Refactoring for Reentrancy, was on refactoring existing Java code to make the code reentrant. The benefit of a reentrant program is that the program can run concurrently on multiple cores without interference. This will hopefully allow for performance benefits when run in parallel on multiple cores.

The authors approached the problem by looking to use thread-local storage for global variables in order to isolate concurrent tasks. Other tasks such as removing potentially unsafe calls to shared libraries and handling static initializers were also required for a functional solution. In order to assist developers in making the required code changes, the authors created an Eclipse plug-in.

Overall, I think this paper follows with a trend that we are seeing where researchers are trying to bring parallel programing to the mainstream and make it more of a "norm" than an exception. While I think the ideas presented as part of this paper are interesting, in my opinion it still falls a bit short. The developed plug-in seems incomplete and a non-trivial amount of developer involvement is still required to make things work. The performance timings also seem a bit inconclusive. Are the realized performance gains truly worth the effort? I'm not sure.

Rereading the Classics (BA ch 14)

This is it ... the final chapter in the book Beautiful Architecture that we will be reading for CS527. It has been a good read. I liked the format of different authors/system designs per chapter most of which I agreed with and liked, a couple I didn't. As for this last chapter, the title is "Rereading the Classics". Classics serve an important role in education. In most cases, they help to present an unmuddled view of the topic at hand and explain/present materials in ways that seems natural and easy to understand. After all, if they didn't they probably wouldn't be classics!

The final chapter introduced Smalltalk. Having come from a predominantly C/C++/C# background, I have to say this language took me a bit to wrap my mind around. I liked what I saw. I think the language deserves a lot of credit in paving a new way of approaching things even if it is not necessarily considered "mainstream".

The last section in the chapter introduced several different structures created by famous architects. Some of these structures while considered beautiful and works of art were not necessarily the most habitable of places. One such structure was deemed inhabitable by its occupants, but yet is still looked at as a modern architectural marvel. This begs the question ... can form and function not be counteractive forces? I think so.

A Java Fork/Join Framework

The Java Fork/Join framework developed by Doug Lea is a framework that aims to simplify parallel programming type tasks. The framework is particularly suited to divide-and-conquer type algorithms where tasks are recursively split into smaller tasks and then executed. Results are then reassembled after all subtasks are completed.

Overall, the framework is pretty small. I think I saw a quote in the write-up that the entire framework was somewhere around 800 lines of code. At a high level, the framework uses a thread pool with task runners to execute tasks. This avoids some of the performance penalties associated with the Java Thread class. I liked the work-stealing algorithm implemented using the double-ended queues.

Performance of the framework seemed to be reasonable. I would be interested in seeing updated performance results using a more recent version of the JRE. I think when this paper was published, the author used version 1.2 of the JRE which is fairly outdated in today's standards.

GNU/EMACS: Creeping Featurism is a Strength (BA ch 11)

I have to admit, I am one of those people that never felt comfortable with Emacs. I'll use it if I have to, but that is about the extent of it. Overall, the whole concept of Emacs add-ons almost seemed a bit like the new version of web apps where end users are generating the content and driving traffic to the site. In this scenario, it is the open source developers and some end users of the application that are developing add-ons that are being rolled into the source tree.

I liked the way in which Emacs handled the buffers, frames and windows isolating the complexity of screen refreshes from the add-on developer. Only having to focus on the core "business logic" of the macro is a big plus.

I think a big reason for Emacs success is in its flexibility and ease with which its base functionality can be expanded upon. It reminds me of two separate systems that I have worked with in the past. Both systems contained screens with a bunch of buttons that could be used to carry out various tasks. One of the systems exposed an object model and allowed users the ability to link the button presses to custom javascript functions. These javascript functions could then manipulate the DOM as desired. The other system was identical in purpose, but the logic for the button actions were compiled into the application binary. Any changes to the button press functionality would require modifications to the application. One of these applications was successful and the other was viewed by many as a failure. Do you want to guess which one was successful?

Our Pattern Language

Hardware trends in recent years have definitely shown the need for an increase in parallelism. The number of processor cores seems to be increasing at a fairly steady rate. If this truly is the trend of the future, parallel software is a must.

The Our Pattern Language (OPL) initiative is a project with a goal of helping to foster parallel development through the use of patterns and a conceptual framework. To date, OPL has been organized into several different layers: architectural patterns, computational patterns, parallel algorithm strategy patterns, implementation strategy patterns, and concurrent execution patterns. The lower layers are where most of the work has been focused to date.

I am excited to see how the future unfolds in terms of parallel programming. It is definitely a trend that needs to be on any developer's radar and will almost certainly continue to shape the development landscape over the next few years (decade(s)?). The degree to which he/she may need to engage will be driven to a certain degree on the type of projects that they work on. However, I think it is important enough and definitely warrants at least some thought.

Metacircular Virtual Machines: Jikes (BA ch 10)

Just coming off of a read about a java PC emulator, we are asked this week to read about metacircular virtual machines. A metacircular virtual machine is a VM where the runtime environment is coded in the same language as that being hosted. In the case of Jikes, Jikes is coded in Java and acts as a Java runtime environment.

The obvious question for such systems is how are they bootstrapped? A good portion of the chapter is spent talking about how this feat is accomplished and the overall design of the system. I personally liked the portion of the chapter that talked about some of the virtual machine myths.

While Jikes is interesting, my overall question as with the JPC case study is the applicability of the system and how/where it would be used. I think it the case of both systems there are some definite academic uses.

Adaptive Object Model Architectural Style

Today, change is constant in business. Whether it is processes, pricing, supply chain, etc. the rule of thumb at least from my perspective is that things will change. The adaptive object model is a great way for developers to try and curb the consequences of change and be able to adapt quickly.

Early in my development career I used to despise systems like these. They were hard(er) for junior developers to understand and get up to speed with. But as I matured a bit, I see the value in systems like this. Not having to interrupt my current work to go back and make changes to previous systems to support new requirements is a great plus for everyone involved. The business can adapt quicker and hopefully there will be fewer potential bugs as well.

Building the GUI of such systems can be challenging though. The chapter introduces some concepts on how to handle this issue along with some good case studies. Overall, two thumbs up!

JPC: Java x86 PC Emulator (BA ch 9)

PC emulators by nature are slow. Layer on top of that an emulator written to run in a managed environment such as java and they are *really* slow. So the question I had when first reading the title of the chapter is why? Why would anyone want to do this? One of the core performance metrics of any emulator is performance. That is of course the target of emulation is something comparable to the current applications being run on the native hardware (ie you are not emulating an original Nintendo Entertainment System using a quad core 3GHz Xeon processor).

I will admit though the authors make a pretty good case (although I am still not sure I am fully a believer). I did like some of the discussion on the performance challenges the authors faced specifically in regards to the complexities of class loading and the processor protected mode/memory performance bottlenecks.

All in all it was interesting learning about the platform and the java performance tips that were shared. But my question still stands … is it useful for anything other than research? What do you think?

Big Ball of Mud

When I signed up to present on this paper, I had no idea what exactly it was about. I was not disappointed! The authors description of a big ball of mud in the opening paragraphs drew me in: "haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle."

I liked the content and thought it was a fresh perspective on what occurs in real world systems. I think that overall several topics seem to be repeated and that the paper could have been pruned down a bit. The HTML formatting was also interesting ... it wasn't the typical conference paper format. Perhaps a play on the "big ball of mud" concept?

Guardian: A Fault-Tolerant Operating System (BA ch 8)

The Tandem/16 NonStop hardware was the Sherman tank of computers. Redundancy and fault tolerance were built in from the start. The designers premise that things will fail and taking a proactive approach in this regard was great. Personally, I have never worked on one of these machines myself. I would be interested to hear from others who actually have. Did the machines truly fail with a slow degradation of services or was one or two failures enough to set off a cascading avalanche of failures rendering the machine unusable? How was performance compared to other machines from the same timeframe?

There is no doubt that these things were beasts. It was a remarkable piece of engineering and it would be great to see more of this type of thinking in our PCs of today.

Layered Architectures

Layered architectures help to provide a natural level of abstraction between components in a system. We see this pattern all the time in practice. As the book points out, one of the common uses of this pattern is in situations like the OSI network model where requests propagate down through the layers and responses return in the reverse order. In theory, layers are isolated from each other using well defined interfaces. In practice however, this separation can be difficult to achieve. Competing forces such as performance and error handling chip away at these boundaries.

Additionally, layering can introduce unintended consequences. Take for example the TCP/IP model discussed in the text. TCP assumes that a packet loss at a lower layer is due to network congestion. In response to this action, TCP reduces the congestion window and attempts a resend after a predetermined timeout interval. However, what if the standard ethernet datalink layer was replaced with a wireless implementation? Packet loss in a wireless network could simply be due to interference. The proper response to this type of error would be immediate retransmission. However, due to the layered architecture, the upper TCP layer is unaware of the reason as to why the packet was lost and cannot differentiate between the appropriate responses. In an effort to resolve this type of situation, interfaces between layers would need to be refactored to add in the appropriate conduit for data sharing.

One positive attribute of the layered architecture is that it promotes buildability. Interfaces between layers can be well defined and specific layers can be assigned to specific resources and worked on and unit tested in parallel. Once coding is complete, layers can be combined and should hopefully integrate with minimal additional effort.

Xen and the Beauty of Virtualization (BA ch 7)

Let's face it ... Virtualization is just plain cool. The problem though is that when virtualization began to gain renewed popularity about five to ten years back, the x86 hardware was not "virtualization friendly". Many protected mode instructions had to be trapped in protected mode and emulated. This was costly. Device I/O and DMA was also difficult. Xen worked around these issues by using paravirtualization which required replacement of all instructions in the guest operating system that were difficult to virtualize with a system call to the host hypervisor. The adavantage of this approach was that performance was good and the added costs of emulation was avoided. The downside was that the guest operating system required modifications. This type of virtualization was rarely supported by commercial OSes.

Now let's fast forward a few years. Virtualization is gaining increased popularity and hardware vendors are beginning to react. Both AMD and Intel introduce hardware support such as an IOMMU within their processors to ease the virtualization overhead previously experienced. With this shift, the performance gains of paravirtualization also began to diminish. This leads to a fairly radical design shift in Xen 3.0 in which support for hardware virtualization is also added.

I think there is still a lot to come in regards to the future of virtualization. Hopefully Xen will be there and continue to provide an open source alternative to the commercial products.

Facebook: Data Grows Up (BA ch 6)

The whole time I was reading the chapter on Facebook integration I kept thinking to myself, "Man ... what is something really cool that I could write to use these APIs?" Then I started to think about the business drivers Facebook was being presented with that drove them to develop the web service interface, FQL, FBML/FBJS. Obviously there is a desire for third party applications to be able to tap into the Facebook data as it can be extremely valuable for marketing purposes. However, Facebook has to figure out how to meet that demand but still keep the data "under wraps" as it is one of their core assets. This is what I think drove the decision of FBML/FBJS as it gave Facebook a way to allow third-party applications access to the data that they wanted without giving them access to the data itself.

Personally, I am not a fan when more and more competing standards or frameworks are introduced to accomplish the same task. For example, did Facebook really need to go as far as designing another HTML and JavaScript variant for providing a safe sandbox for these third-party applications? Could they simply have used HTML and JavaScript as they exist, but do some strict parsing before presentation to end users? I'm not sure in this case...

Pipes and Filters

What more can I say? Pipes and Filters is a solid style that has been around for at least as long as I have been working with computers. The ability to pipe input from one filter to another (maybe in the same process maybe not) breaking the work into distinct tasks is something that is easily understood and lends itself to making a system that is simple to build, easy to maintain and future-proof to a certain degree. The added benefits of being able to reconfigure/add/remove the order of filters or topology of how filters are applied (sequentially, in parallel, in a different order, etc.) is also a great benefit.

Excerpts from Christopher Alexander

Christopher Alexander has a unique style of explanation that I find quite interesting. Normally, I am not one to ponder the meaning of life or one to try and draw parallels from seemingly different ideas. I tend to see things in black and white (with maybe one or two shades of grey shimmied in between). However, I think Alexander makes some good points and I do think there is an alignment between building architecture and software architecture.

The main takeaways that I got from Chapter 9 were that we should trust in the process. Define the architectural style and allow it to guide the project to completion. Software projects today are more elaborate and complex than ever. Having a single architect attempt to design every line of code in a system is most likely to end in failure. Chapter 10 goes on to talk about pattern languages which are unique in the way that they are interpreted. They provide the framework for building and help to explain why "things" are built in the manner in which they are and the uniqueness but yet similarities that exist between them. The final excerpt concludes with several general "rules of thumb" for building. All in all very interesting!

Resource-Oriented Architectures (BA ch 5)

I enjoyed reading this chapter in the book. I liked to hear the author's perspective on why RESTful architectures are a good thing. A few years back I worked on a project that was implemented using Ruby on Rails and just recently we finished up a project using ASP.NET MVC framework. Both were very similar business applications ... they managed and provided a front-end to a bunch of data in a database (exciting I know!). Using this type of architecture seemed to be a natural fit and scaled extremely well.

One thing about the chapter that I am not sure I followed was the author's distaste for web services and issues with versioning. At the end of the day, web services may not be easiest beasts to tame, but can be useful.

ArchJava: Connecting Architecture to Implementation

ArchJava is an extension to Java that enforces communication integrity meaning that components only communicate with components that they are explicitly linked to in the architecture. This enforcement is a good thing. It turns out that as developers we aren't too good at abiding by the communication paths documented in a system architecture. Shocking I know! A framework like ArchJava forces the implementation to follow the communication paths outlined.

From a system design and documentation point of view, this is obviously good. But can tying the architecture to the implementation be too restricting? I don't think so. Can it take more time to code in this fashion? Probably. Is it worth it? I think so.

Making Memories (BA ch 4)

Hmm ... not really sure what to say about this chapter. Overall, I think the author laid out a clear picture of the development process of a software system to power a photography studio chain. The system consisted of components running in branch offices and corporate locations with data being shipped back and forth via DVDs. The system as a whole was a key requirement for the business to function. Without it, photographs could not be editted/uploaded, pictures could not be printed, customers could not take delivery of their orders, etc. But when I finished reading the chapter, I asked myself what did I actually learn? What were the key take-aways that should have sparked that Aha! moment? If someone has an opinion on this, please let me know! I guess there were some interesting points about the competing forces of business drivers and software development, some other good stuff about separating concerns (such as they didn't want any business logic in the UI for example).

One thing I was questioning though ... why go through all the trouble of building a whole subsystem for branch office clients/servers to exchange files? Why not just use thin clients as the end user terminals and have all software components run on the server? No more need for file transfers! Not to mention reduced support costs as you wouldn't have to administer/patch/update client PCs. Maybe you could argue that this would introduce more of a single point of failure, but if that is really a strong concern, add a second server and create a redundant cluster...

"4+1" View

Let's go back to my first day on the job after graduating from college:

Plunk! A book lands with a thud on my desk. "Hmm ... What's this?" I ask. "It's your training manual." says my boss. "Rational Unified Process? Interesting." I spend the next week pouring through the book trying to learn the correct way to build software. The "4+1" model was part of the documentation that I was asked to read.

I learned some things and ignored some things. I figured out early on that Rational Rose and Visual C++ were enemies. I also found out that as a consultant we were rarely called in to develop projects from the ground up. Usually we were called in to help out on the Messy Metropolis type projects of the world. Going back and creating documentation for an existing product (that had none) was rarely something that clients wanted to pay us for.

In all honestly, I like the "4+1" model. I think it is flexible and can be easily adapted to the type and size of the project being worked on. Clients appear to like it as well and seem to be able to understand the documentation that we produce. The fact that I have continued to use a loose variation of the model for the last ten years should be worth something. Right?

Architecting for Scale (BA ch 3)

Having read the chapter, it almost seemed to me that the author's were really trying to find a sort of "holy grail" of parallel computing. The thought of taking an application that has little or no knowledge of parallelism and being able to deploy it on a magical cluster that handles the concurrency and scheduling issues behind the scenes would be a huge feat. Just think of it ... none of us would even have to learn how to write parallel applications!

I question the application of this architecture for the MMO space as the authors intend. It seems that a major concern with these games is latency. The authors freely acknowledge that this system may be more prone to latency than other solutions in use today, but seem to brush off the importance. Are the authors out of touch with the requirements of their audience? Is the system doomed to fail from the start?

I would have also liked to see more details regarding performance. Yes, I get that there are no readily available benchmark suites that they can run to sort of gauge the performance of this architecture vs. existing architectures. However, I think the authors could have at least provided details regarding transactions per second for varying number of nodes or comparison of tasks per second for a single host cluster vs. 10, 20, 50, 100 ... node systems. Does the system scale linearly with the number of nodes or do additional nodes experience diminishing returns in regards to performance metrics? And is there an upper limit to how big this thing can scale?

Toward Boxology

Shaw and Clements propose that the choice of architectural style can be a function of control and data issues. On the outset, I'm not sure I would have come up with the same classifications. Having read their work though, I do think it makes some sense. I just question the ability to fit every project neatly into one of these boxes. Functional and quality requirements can be so different for each situation. I think this classification of architectural styles should simply be treated as another tool in the toolbox so to speak.

The one point that the authors highlighted that I appreciated were that the community needs to work towards a common language for speaking about architectural styles.

A Tale of Two Systems (BA ch 2)

While reading this chapter, I almost started to break out in a cold sweat. I worked on a project that was The Metropolis. If you have been fortunate enough (or are young enough) to not have had the pleasure of working on such a project ... good for you. For those of us who have, you know that the experience is something that you will never forget. To this day that code still haunts me! Having survived it however, I will say that I think everyone needs to have the experience at least once in their lifetime to truly appreciate the benefits of a good architecture and development team.

As for the Design Town project, there were a couple of points the author brought up that I thought were interesting:

• Technical Debt - I like the concept. While I have never used this particular approach on any of my projects, I think it has potential.
• YAGNI - I see it all the time. Developers like to "over engineer" by nature. Yes, I understand that someday you may need it, but why not refactor the code when that day comes?
• Development Team Morale - I think organizations tend to underestimate the impact of morale on employee productivity and product quality. The relationship between architectural quality and morale is a two way street. A poor architecture leads to poor morale and poor morale leads to a poor architecture.

Understanding Quality Attributes (SAIP ch 4)

The chapter was a good read. I think the authors did a good job of laying out a high level framework for identifying various quality attributes. I particularly like the focus the authors placed on the impact of business drivers in the software development lifecycle. From my experiences, these drivers are of increasing importance (many times even more so than other quality attributes).

I would like to see a written list of concrete scenarios for an actual project. It seems like the list could grow rather quickly with all of the permutations of variables.

What is Architecture? (BA ch 1)

At a high level, I think Spinellis and Gousios did a good job of introducing the concept of software architecture. When I first picked up the book, I wasn't aware of the fact that many of the subsequent chapters were actually based on "real world" architectures. After having read the first chapter, I am definitely excited to read on and see what else the book has to offer.

Having said all that, everything can't be sunshine and roses! There were a couple of points in the first chapter that either I didn't fully agree with or wish that the authors could have provided more concrete examples to help explain. Here are a couple of the highlights:

• On page 10, the authors claim that an architect's first concern is not the functionality of the system. Instead, it is the quality concerns that an architect should begin with. While I agree with this in principal, it is my experience that this is not typically the case. I wholeheartedly believe that a good architect should think this way. However, for every good architect I think there are tens (maybe hundreds? :)) of bad architects. Why is this? I think it stems from the fact of how architects are promoted within Corporate America. Typically, they are not necessarily the most skilled individuals on the project team ... just the ones who have been there the longest! Most either have no or very limited formal training on how to perform their jobs effectively. (Hmmm .... I wonder if this is how developers working on projects where I have served as the lead architect feel?!@?)
• Something that is not really discussed in much detail in the chapter which I feel is important is in regards to the cost-benefit trade offs of quality concerns. Does it cost more to build systems that are highly available, scalable, easy to test, have great performance, etc., etc.? I think that these systems definitely tend to be more complex, but it is not always easy to determine the impacts to costs or the monetized benefits of such a design. For example, people who wear suits like to perform cost benefit analysis exercises. For things like increases in performance, this may be fairly easy. With Architecture A, I can support Y transactions per second, but with architecture B that only costs me $1 more I can support Y+20 transactions per second which equates to $1 million / year in added sales. Yeah! But how do we quantify the realized benefits of a system that is highly scalable or easily modifiable?