Thursday, August 9, 2007

Bartlett's Err, Rajapakse's Familiar Quotations

Bartlett's Familiar Quotations is a great place to explore "sound bites" from great literature. I find them useful for lectures, papers and t to explore some interesting nooks and crannies of great literature by taking the quote and then "reading around it" to get the context. In fact John Bartlett had a great quote about his quotes, "I have gathered a posie of other men's flowers, and nothing but the thread that binds them is my own."

Several weeks ago (by way of doggdot, I think) I discovered Damath Rajapakse's collection of Software Engineering quotes and had a great time sampling the quotations. Dr. Rajapakse has done a great service for software engineering students and lecturers alike. It is a highly recommended site to visit and bookmark, especially for folks interested in software engineering. Enjoy it and thanks to Dr. Rajapakse for creating such an entertaining and useful compilation.


Tuesday, August 7, 2007

Architectural Attributes

Hard to believe I am still working my way through posting great log entries from folks in the Spring term. This log entry from Deborah Ford in my Software Architecture and Design Class at Stevens lists great attributes for a software architect. I like that she emphasizes domain knowledge, breadth of experience, communication skills and mutual respect (architect should respect designers and developers; designers and developers and designers should respect the architect). In many ways that is a great formula for any leadership role but it is especially the case for the architect. I would like to thank Deborah for letting me share these with you. The key excerpt from Deborah's log entry:

Out of this (my experience) I’ve concluded that there are certain keys to success for architecture teams:

1. This isn’t necessarily a job for the most creative designer or best technician. It is more important to get someone who understands the big picture and can bring differing views to consensus or make a judgment when the situation calls for it.

2. Don’t farm out architecture roles to outside contractors – you are investing your knowledge capital in people who don’t have such a compelling reason to stay and can be at the whim of budgetary fluctuations. You are also giving lots of domain knowledge that your competitors may be able to take advantage of further down the line.

3. Team members should have a wide exposure and not be too wed to any particular technology or internal organization. I am wary of people who have spent their entire working career in a single organization.

4. They must be people who have the respect of the teams that they work with.

5. They must have a good grasp of the business domain.

6. They must not be seen as too allied with any single development organization

Hopefully, I will increase my volume of posts in the next few weeks since I have some backlog and a fresh stack of 30 logbooks to read from my summer classes! Later!