Beautiful Architecture: Chapter 3

Chapter 3 of Beautiful Architecture presents the designing of project Darkstar, a framework for MMO games and virtual worlds.

I enjoyed seeing how the decisions were made in identifying problems and the best solution for the framework. I can relate to their issues of developing frameworks for other people to use transparently. They still had to educate developers on how to create objects that do not defeat the parallelism available. I developed a framework at work for other people to use, along with a complete user guide on best practices for keeping modules self contained, etc. Still, other developers would break rules and cause issues, showing the need for better education or validation =) It's fun to see other people start to use stuff you've created

Field Guide to Boxology

The authors of this paper put forth the idea of architectural styles, and trying to define common patterns used for solutions, not problems. They classify mainly the styles used for handling data and communication in architectures, then suggest patterns to follow based on need.

I enjoyed their breakdown and thought it was interesting, but is it enough? The job of the architect is far from over after picking the needed data communication. How execution is structured, style, modularity and many other concerns will still have to be addressed. Should these be categorized too? Does one type of data architecture naturally lead to one type of process for development? This paper is a good start, and opens the door for more research in the field.

Beautiful Architecture: Chapter 2

Chapter 2 of this book was a case study: A Tale of Two Systems. The first was poorly designed and a disaster to work on, the second well thought out and enjoyable for the developers.

I found it interesting how much the process helped the second, good system, with eXtreme Programming being used. How much do you think the process used affects the system for good/bad? I think it has a rather large impact, due to the numerous facets a process addresses, such as style, design documentation, etc., which can make it easier for others to follow what is happening. I've worked on a couple of CMMI projects, which can output a large amount of documents, some rather unnecessary. However, it was required by the customer and thus necessary to the success of the project, plus we were able to remove parts that made no sense for small projects. A dose of commen sense can go a long ways =)

Beautiful Architecture: Chapter 1

This book shows how to design software architecture through examples. The first chapter is expected background, defining terms and what architecture is. I liked the comparisons between physical architecture, musical architecture and software design.

I saw one comment on another blog related to this claiming that all developers should be architects. Would you agree that this is the case? Based on experience, I don't believe this is necessarily true. While anyone designing software is to some degree an architect, not all programmers need to be architects. Once an architect has set a style and assigned a module to some programmer, that programmer does not need to have design skills. At my company, new college graduates fall into this category typically. Sure the work needs reviewed to ensure the assignment is fulfilled, but the programmer does not have to worry about the big picture or creating standards, that is done by the architect.

Any comments?

First Post

Sadly, I must now begin a real blog =( Since this is for a class on design patterns, I've named it so that it may be used after the class, yet still make the several posts following half-way relative to the topic.

After this course is over, I may yet turn a different type of pattern - a pattern for life in general. Enjoy!