Last July, I posted a book review on Framework Design Guidelines.  At that time, I had started to read a technical book once a month and post a review of it on my blog...or at least attempt to do so.  I managed to stick to it for about three months, but the hectic nature of the holidays (among other things) wore me down and I stopped doing it.

I have decided to resume the monthly book reviews in February (as if I didn't have enough to do already).  I started reading some of Applying Domain-Driven Design and Patterns, which had been lying around for a couple of months collecting dust.  I also have pre-ordered Juval Lowy's Programming WCF Services, which is supposed to ship next week.  I'm very anxious to see the depth of information it provides. 

One of these books will likely be the next one that gets reviewed.

I missed the September issue of my monthly book review.  Since it was due to the craziness around the birth of my first son, I will cut myself some slack.  Anyway, I was in the process of reading Service Oriented Architecture: A Planning and Implementation Guide for Business and Technology by Eric A. Marks and Michael Bell.  Before I get into the book, I must make a confession about my take on SOA.

Over the past few months, I have been trying to get a better understanding of what SOA is really all about by separating fact from fiction.  As embarrassing as it may be, I must admit that I originally felt mesmerized by the bright, flashy, neon signs created from all the religious rants by "experts" and marketing hype full of false promises that are rampant across the entire industry.  If you're not careful, it is pretty easy to get caught in a trance going "ooo...S..O..A". 

After a lot of thought on the matter, I now find myself beginning to share the opinions of people such as Rich Turner and Clemens Vasters.  They have more eloquently described their position on the subject than I could.  So, you should refer to their blogs for a thorough explanation, but the general idea is that SOA is a misnomer. 

Personally, I am a big believer when it comes to service orientation (SO).  However, SO is merely an abstract set of principles used to provide guidance for best practices in building distributed systems.  When you attempt to create a software architecture around these tenets, it will inevitably be incomplete because they do not address all issues of a software architecture such as data analysis, data mining, data visualization, etc.

At any rate, enough of my ramblings about SO(A).  This post is supposed to be a book review.  However, due to my stance, it probably isn't the most useful review I have ever written.

First of all, this isn't your typical technical book.  The title should tell you that much.  It attempts to explain the role of technology and the role of the business within the context of SOA.  Consequently, the book is mostly conceptual.  There are no code samples and you won't find it referring to any specific technology.  However, this shouldn't be perceived as a bad thing.  SO(A) is supposed to be technologically agnostic.

Depending upon your expectations, you may find some very dry reading.  It attempts to address a pretty wide audience.  The first section is targeted specifically at explaining the business value for SO(A).  The second section is focused upon the concepts involved with analyzing and designing services.  The last section is all about governance, policies, metrics, and return of investment (ROI). 

If you are looking for a book on SO(A) that covers all of these topics, it is probably the best you will currently find.  However, if you are looking for more information about a particular facet of SO(A) or want to read about its implementation on a specific platform, you should probably look for another resource.

To the credit of the authors, I think they have gone a long way in providing some clarity around a topic that has been littered with hype and confusion.  It covers a lot of ground in some of the "dark corners" of SOA such as governance, policies, and metrics.  Overall, it does a good job explaining an enterprise level approach to service orientation that may work well for some companies.  At the very least, it contains a lot of conceptual level information that is useful in the domain of service orientation and distributed systems.

On a scale of one to five, I would rate this book as a four.

The next book review will be Pro .NET 2.0 Extreme Programming.

A couple of months ago, I decided to make myself start reading a minimum of one technical book per month.  The goal is to shoot for two, but I must read at least one.  As I read a book, I am going to post a review about it on the blog.  Last month, I read Framework Design Guidelines.  This month I have just finished reading Software Estimation: Demystifying the Black Art by Steve McConnell.

Obviously, McConnell is already a very well-known author from previous books that he has written such as Code Complete and Rapid Development.  Once again, he has delivered a technical masterpiece that should be required reading for anyone responsible for estimation.  All of the material is delivered in a sensible manner that is easy to comprehend.  I have gained a signficant amount of insight into the entire concept. 

The book is split into three parts.  The first part is about critical estimation concepts.  It covers a lot of important information that serves as somewhat of a primer for the remainder of the book.  McConnell does a good job clarifying the difference between an estimate, a target, and a commitment.  Even though it is sometimes easy to blur the lines between them, each one is unique and has a specific purpose.  He also covers some good information about the distinctions of accuracy and precision.  In typical conversation, these terms are often used to convey the same meaning, but they are not really the same thing, especially when it comes to a software estimate.  The section also discusses some of the important issues that influence estimation as well as problems that lead to estimation error.

The second part of the book is about essential techniques for creating estimates.  One of my favorites is what was referred to as Count, Compute, Judge.  Basically, this refers to the idea of counting as your first course of action.  If there is a way to directly count some value to provide the estimate, it is the your best option since it usually provides the most accurate result.  When you can't directly count the answer, you should compute the answer by counting something else that is related.  If you can't count or compute, you should use judgement only as a last resort as it introduces the greatest opportunity for bias and error.  A lot of this is may seem obvious, but it is often neglected in practice.  Some other estimation techniques that were examined include Calibration via Historical Project Data, Decomposition and Recomposition, Proxy-Based Estimates, Estimation by Analogy, and more.  It should also be noted that McConnell provides some guidance as to which of these techniques work best for sequential software developement and iterative software development as well as the level of accuracy (low, medium, or high) that is possible with each technique and the point(s) in the project when it is most useful (early, middle, or late).

The final part of the book is about some of the specific challenges involved with software estimation.  It covers a lot of the pros and cons of various ways to estimate size, effort, and schedule.  McConnell also gives some tips about the best manner in which to present your estimate.  He also provides some practical advice about the political atmosphere that often accompanies software development.

On a scale of one to five, I would easily give this book a five.  It is an excellent resource for practical advice about software estimation.  Anyone that is involved with estimates would benefit from reading this book.  Even if you aren't directly involved with software estimation, it would be advantageous to read this book for anyone that wants a better understanding of the ingredients of a successful project.

This was the last of the books that I had lying around waiting to be read.  I ordered three new books from Amazon earlier this week.  As soon as they arrive, I will get started reading my next one.  Here is a list of the books to give you a preview of the upcoming book reviews for the next couple of months:

Service-Oriented Architecture (SOA): A Planning and Implementation Guide for Business and Technology
Applying Domain-Driven Design and Patterns: With Examples in C# and .NET
Pro .NET 2.0 Extreme Programming

I have been reading Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries.  This is already a well-known book within the .NET community and certainly isn't lacking of excellent reviews.  However, I have been so impressed with it that I couldn't resist throwing in my two cents as well.

First of all, it was written by Brad Abrams and Krzysztof Cwalina.  These guys hardly need any introduction.  Brad is a Program Manager for the .NET Framework.  He is one of the masterminds behind the design of a lot of the class libraries for the ECMA CLI specification.  Krzysztof is a Program Manager on the CLR team.  He has also been involved with several of the prominent namespaces of .NET and was one of the creators of FxCop.  These are a couple of really sharp guys that possess a wealth of knowledge about .NET.  It's hard to go wrong with authors that have such distinguished experience.

The book is a very good read.  The intended audience seems to be primarily developers and/or designers of frameworks or class libraries.  However, it would certainly be beneficial to any serious developer that just wants a greater understanding of some of the fundamental design of .NET.  In my opinion, it should be a required read for any developer that will be writing code used by other developers. 

The authors do an excellent job providing practical advice in the form of Do, Consider, Avoid, and Do Not.  They cover a lot of important topics ranging from naming, type design, member design, extensibility and usability considerations as well as exceptions and common design patterns.  Even if you aren't the type to sit down a read a book like this from cover to cover, it would be worthwhile to snag a copy and hold on to it for reference purposes.  If your position involves a lot of design/development of libraries used by other developers, then it would definitely be a good reference to have on hand.

Don't take my word for it.  Go out to the Amazon link for the book (see above) and read some of the customer reviews.  There are several people that are capable of elaborating the praise of this book far better than I can.