Software Architect Bootcamp, Second Edition

Rating:
Summary: Inappropriate analogies for software development
Review: While I admit to occasionally using the phrase "in the trenches" to describe software development, I generally consider military analogies to be inappropriate descriptors of how software is created. A military organization is composed of a rigid command hierarchy where orders are not to be questioned. No software development shop could ever be run in this manner. Military subordinates can be screamed at, ridiculed and within general guidelines that are sometimes exceeded, abused. Once again, that strategy does not work in the business world.
The worst military analogy offense in the book is chapter ten, "Psychological Warfare." While keeping a team functional using psychological techniques is a well-known tactic, the means of psychological warfare are completely different. The authors admit this when in the chapter they utter the sentence; "Mastery of these techniques should provide tools for effective persuasion in both group situations and face-to-face interactions." There are many problems in that sentence. An argument that techniques used to psychologically weaken an enemy in warfare will prove effective in working with team members in a business setting is absurd. Also, there is the key word "should", a weak word indicating that the authors are not convinced that these tactics will work.
This absurdity also appears on the back cover in the form of the blurb, "With hands-on exercises, real-life war stories and a take-no-prisoners attitude, `Software Architect Bootcamp, Second Edition', won't just help . . . " I have no idea how the authors of this book conduct their businesses, but in the development teams I have worked with, that kind of tactic destroys the consensus necessary for people to work together effectively. In fact, I have no idea what a "take-no-prisoners attitude" is supposed to mean in a software development environment.
While I found the military wording to be an unnecessary distraction, there is some good advice in the book. Using architecture in the same sentence as software is a relatively new phenomenon. Recently, the complexity of applications has grown to the point where developers have split into different areas. There are still people who write the code, but now there are others whose fulltime job is to develop and manage the overall structure of the application. These people, commonly called software architects, need to be trained in ways completely different from the code writers. While they need to learn how to put software components together, they also need to be trained in how to articulate their vision and convince people by rational argument. The authors cover the different aspects of software architecture and end each chapter with a set of essay questions that are partially answered.
I really have ambivalent feelings about this book; it does contain a great deal of useful information regarding software architecture. However, the absurd analogies weaken it when compared to others, so that is why I only give it two stars. I would not use it to train software architects.

Rating:
Summary: Just a bad hash.. or is that hack.
Review: ... Warning: too much rambling ahead.
// Read at your own risk.
...
I perused this text at length in the local bookstore. I did not find much of merit for my own personal use, but someone else might find otherwise.

I concluded that, (probably like most people that would pick up this book), I've already had a lot of the experiences outlined in the book. This includes code reviews and walk through, project planning / management, dealing with non-technical people, being a diplomat, evangelist, mentor, as well as (whoa!) being an actual developer, too.

IMHO, this book is a somewhat glib re-hash of basic material you can glean from more comprehensive sources, such as "Code Complete" (Steve McConnell, Microsoft), which is itself a codification of studies and findings from other software sages.

I think the authors put far too much emphais on particular technologies, some of which are swiftly losing relevance, ie, COM+ and ActiveX. When I saw these terms, I checked the publishing date. I expected to see 1998, but found 2001!!
I don't think that a credible text on building an architecture career should be pushing any particular implementation technology. Many technologies are not built on anything new, but are simply re-hashes of RPC, wrapped up in newer clothing... rather like the content of this book. However, in it's defense, the text did acknowledge that the most important thing is that our tech careers demand a lifetime of learning.

You can gain a lot better understanding of topics mentioned in this book by arming yourself with such texts as Code Complete, a good UML text, a good Patterns book, a lot of seasoned development experience, and perhaps even a 14 week Dale Carnegie course so you can learn to let other people think that they thought of <topic "whatever" /topic> before you did. However, you also have to be willing to step up and accept some project leadership roles, and be willing to deal with tech or non-tech people at various levels.

Postive: nice cover, not heavy, no cute graphical layout clutter, good introductory text for a non-technical manager to read.

One excellent note: the authors made a very good recommendation about how to stay on a tech path. They advise that you make your desire and goals clear to your non-tech manager, and occasionally repeat them every few months. They also warn against rising so high in the organization that you begin to be tapped for managerial roles that you don't want.

Here endeth the sermon.

Rating:
Summary: Just a bad hash.. or is that hack.
Review: ... Warning: too much rambling ahead.
// Read at your own risk.
...
I perused this text at length in the local bookstore. I did not find much of merit for my own personal use, but someone else might find otherwise.

I concluded that, (probably like most people that would pick up this book), I've already had a lot of the experiences outlined in the book. This includes code reviews and walk through, project planning / management, dealing with non-technical people, being a diplomat, evangelist, mentor, as well as (whoa!) being an actual developer, too.

IMHO, this book is a somewhat glib re-hash of basic material you can glean from more comprehensive sources, such as "Code Complete" (Steve McConnell, Microsoft), which is itself a codification of studies and findings from other software sages.

I think the authors put far too much emphais on particular technologies, some of which are swiftly losing relevance, ie, COM+ and ActiveX. When I saw these terms, I checked the publishing date. I expected to see 1998, but found 2001!!
I don't think that a credible text on building an architecture career should be pushing any particular implementation technology. Many technologies are not built on anything new, but are simply re-hashes of RPC, wrapped up in newer clothing... rather like the content of this book. However, in it's defense, the text did acknowledge that the most important thing is that our tech careers demand a lifetime of learning.

You can gain a lot better understanding of topics mentioned in this book by arming yourself with such texts as Code Complete, a good UML text, a good Patterns book, a lot of seasoned development experience, and perhaps even a 14 week Dale Carnegie course so you can learn to let other people think that they thought of before you did. However, you also have to be willing to step up and accept some project leadership roles, and be willing to deal with tech or non-tech people at various levels.

Postive: nice cover, not heavy, no cute graphical layout clutter, good introductory text for a non-technical manager to read.

One excellent note: the authors made a very good recommendation about how to stay on a tech path. They advise that you make your desire and goals clear to your non-tech manager, and occasionally repeat them every few months. They also warn against rising so high in the organization that you begin to be tapped for managerial roles that you don't want.

Here endeth the sermon.

Rating:
Summary: Huge disappointment
Review: A book on software architecture should discuss a number of approaches to architecting software: layers, business objects, pipelines, frameworks, etc. This book has a few ideas, but mostly it's a tiresome diatribe against Microsoft technologies (2 million professional developers should switch just because this author and Scott McNeally says so!), and a verbose marketing brochure for CORBA, Linux, and the Usual wanna-be-as-succesful-as-Microsoft Suspects!

Rating:
Summary: Great! "Architect in a Box"
Review: As a newly crowned enterprise software architect, I needed a complete "Architect in a Box" kit, and this book is it. Learn what software architecture is, why it is becoming so popular, where it started, where it is going, and how to do it well. A must have on any software architect's desk.

Rating:
Summary: An absolute "must-have" instructional and reference
Review: Collaboratively written by two experts in the field (Raphael Malveau and Thomas J. Mowbray), and now in an updated and significantly expanded second edition, Software Architect Boot Camp is a clear, concise, and no-nonsense manual to learning how to devise practical solutions to common challenges, avoid costly mistakes, as well as balance costs versus needs as a software architect. Individual chapters cogently address choosing the right architectural model for one's project; applying abstraction; refactoring; architectural proto-typing; coordinating effectively with project managers and teams; managing a professional software architect career, and a great deal more. Software Architect Book Camp is an absolute "must-have" instructional and reference for any practicing or aspiring software architect.

Rating:
Summary: Don't waste your time
Review: Do not buy this book. It is unclear, confusing, and appears to have been published entirely without involvement from a proof-reader.

Rating:
Summary: Fifty bucks I should have spent in a bar
Review: Fifty bucks I should have spent in a bar, talking to someone who is a practicing architect. The book has two excellent features: every word is spelled properly and the back cover blurb is captivating.

The problem is, the blurb isn't true. Not a single war story. Precious few examples. Lots of discussion of industry standards. Anything Open is good; anything Microsoft is bad. Rational's UML was the only analysis approach discussed.

It's a shame Prentice-Hall didn't devote an editor to the tome. The series editor was a co-author. He should know that you cannot edit your own work. The language is twisted and incorrect, to the point of unreadability. We're not talking John Milton here. These are errors Word's grammar checker would have found.

The graphics were similarly arcane. The author refers to the circles in figure 3.2. There are no circles in figure 3.2.

The most useful prescriptive delivered was a ten step waterfall development methodology. But that's nothing new.

I'd like to take the title, jacket blurb, and concept and see it done again by a practitioner, not someone who had a three hundred page contract to fulfill.

Rating:
Summary: Nice title, shame about the book
Review: Great title, subject and introduction, but the actual book itself is mostly useless, poorly edited and badly written. It doesn't really give you a good feel for what architecture is about, or much good advice either. The book mentions RM-ODP a lot, but its hardly mainstream, in 6+ years of big five consulting in distributed systems I have never seen it mentioned.

Rating:
Summary: Good content, terrible writing
Review: I bought this book looking for a refresher course in basic architecture principles(being in the trenches too long can cause severe memory loss). I looked through the table of contents and was impressed at the amount of information covered.

I have read about half of the book so far, and my general impressions are:

1. The authors of this book are quite in love with RM-ODP and design patterns,
2. RM-ODP is a nice framework, and
3. Nobody proofread this book.

I count no less than five misuses of the word "which" on every page. There is a typo on the first page. I can handle a sporadic typo or grammatical error, but the sheer number of grammatical bungles in this book is inexcusable for several reasons. First, this is supposed to be the leaders of our field writing deep thoughts about architecture. How can I rely on information that looks to be written by a high school student? For [the kind of money it costs] I want an editor to check over the grammar.

I gave this book three stars, however, because the content is good. There is a lot to know in the software field that many technical people regard as "theory" or "academic". Most technical people would rather learn a dozen new scripting languages than open a design pattern book. Most of the information in this book is useful to every programmer, analyst and architect.