Customer Reviews

97 Things Every Software Architect Should Know: Collective Wisdom from the Experts

5 star:		(4)
4 star:		(12)
3 star:		(3)
2 star:		(4)
1 star:		(4)

 

 

Heavy on keywords and low on actual content / value.

Imagine your Dad rings you up and says, "Be sure to go to work bright and early..." or "The early bird gets the worm" and proceeds to ramble on for 5 minutes about why that is important. We have all been through this kind of lecture. For politeness sake, you bite your tongue and zone out.

Now replace Dad with Bill Gates/ Steve Jobs/ some famous architect. However the advice being doled out is similar. eg. "Be sure to have a decent UI for every component/ blah blah blah".
How would you feel if you had to read 97 articles by famous architects / tech gurus, each 2 pages long and the entire content of the article is in the first introductory line itself. The rest is fluff.
I don't know about you, but when I am paying 20+ dollars for a book, I expect more than simple fluff.

-V

This book is just an accumulation random advice collected for "free" off a blog. You will feel like you have read a bunch of fotune cookies (i.e. "The longest trip begins with a single step") on the topic of architecture. Not a single topic is explored in depth since each topic is only 2 pages in length.

I would not recommend this book.

I found many of the contributions interesting, but wished for more detail. Many are not much longer than a page and left me wanting.

Why does a famous (and, he has proven it, excellent) technical writer dare to compile
such a useless, incoherent and impractical amount of pseudo-advice?

His other books provided deep technical knowledge and practical help.

This one's not worth its price - there are much better books available...

alternatives: Taylor et al: Software Architecture (Foundations, Theory and Practice): Great read.
Bass et. al: Software Architecture in Practice: Great read.
Buschmann et. al: Pattern-oriented Software Architecture: Great series.
Fowler: Patterns of Enterprise Application Architecture: Great, highly practical...

So - don't bother with this one, go get a good book :-)

[97 Things Every Software Architect Should Know] is much more broad than most people would expect from its title. It's certainly true to its title, but I expected that it would have be 97 things software architects should know about software architecture. Many of the points, while good advice otherwise, aren't special to software or software architecture. They are points any manager, project leader, or executive could apply. It's really 97 Things Every Project Manager Should Know, although there's already a book for that.

The first thing every software architect should know is what is expected from that job title, and I was hoping someone would at least try to define it. In reality, the title is a dumping ground for the tasks you don't give to the programmers but don't trust to the executives, and the job description varies widely.

My notion that nobody really knows what a software architect should do is reinforced by reading the advice from the many contributing experts, each of which briefly write about what they think is important. Some of that advice conflicts with other contributors, is so general so that the it would suitable in any business book, or merely shows that anyone touching a keyboard might be labelled a "software architect".

I was surprised that a lot of the advice tried to actually force the commoditization of "software architect", as if the actual person doing the job was interchangeable. An architect's experience, vision, and artistry should be at the center of the endevour. Architects are not cogs; they create and enforce the philosophy and design concept. In that regard, I actually only know a handful of software architects. Most people who consider themselves an architect, however, are probably merely applying the design and philosophy that somebody else created.

Setting aside the definition of architect, the advice is good for almost any project leader involved with software development no matter their job title. It's much better advice, however, for the journeyman who wants to be a project leader someday.

As with many management books, anecdotes are rife and facile. They are the sort of things you might mention in an elevator, such as changing the Mach 2.5 requirement of the then-future F-16 fighter plane to "escapes combat quickly", but that anecdote doesn't really help anyone, or at least not in the same way as something holistic and fleshed-out like Skunk Works: A Personal Memoir of My Years of Lockheed. I would have appreciated footnotes or references to complete case-studies.

Given the short format of each contribution, this generality is probably unescapeable. That's mitigated somewhat by the accompanying website for the book where longer discussions might take place. There's no overarching concept or guidance since the contributors are advising in different dimensions, coming from different experiences, and using their own idea of what a software architect should do. Very few contributors talk in terms of the complete software life-cycle; much of the advice in the vein is about requirements research, and even then is mostly about proper mindset rather than useful techniques.

If you buy this book expecting 97 in depth dissertations on software architecture & design, you will be disappointed. It is instead, a collection of observations on the relationships between business, people and technology. This is not a tome that one sits down and reads in a day, acquiring all of the knowledge of the collected contributors in that instant. It is instead a book, which is best read a chapter or two at a time, and discussed amongst your colleagues. Some lessons you will be able to implement immediately, some will not be of value to you ever. Many deal with issues that (as one would expect) will help to make your life easier if implemented in the planning stages of a project. The only thing I would change so far would be to change "Your Customer Is Not Your Customer" to "Your Customer Is Not Your Only Customer" or "Everyone Is A Customer".

I give it 4 stars instead of 5 because as others have noted, it is very lightweight. I do feel that this book would be suitable for most folks in technology to read, not limited to software architects. I would have no hesitation recommending this book to everyone from a Junior Systems Administrator or Project Manager all the way to a Director Of Technology.

This collection of exquisitely chosen expert advice on the highest level design issues for software development adroitly addresses the somewhat diverse definitions of Software Architecture. In a beautiful and excellent edited gathering of two page opinion pieces by leaders of software design and system specification, this brief volume provides much of the accumulated wisdom on how to conduct a large software effort and specify its externally visible components. This advice transcends the borders between technical specification, ways of selecting components, rules of manging large technical teams, and the necessary communication between the business leaders of an enterprise and those specifying the major software structures that will support their work.
It represents the accumulated wisdom of many years and many viewpoints in managing the development of large software projects and will save a great deal of grief for all concerned. One might wish for a unified viewpoint or a top-down hierarchical approach to organizing these pearls of wisdom, but then a short volume couldn't provide the depth and breadth of experience of many experts providing multiple views of the strategic issues and gotcha's involved in specifying and guiding major software development projects. All in all, this is an excellent collection of many years of accumulated wisdom gathered by the leaders of major software development efforts and an invaluable and necessary addition to the library of anyone who will be involved in specifying the externally visible components of a significant software project.

--Ira Laefsky

97 Things you already knew, but had to discover from this book. It's OK if you could rent it at your library for casual browsing. To actually buy this book would be a blunder. Like someone earlier mentioned, most of the free Blogs offer better advices and with greater illustration (not the literal type). It is so rudimentary, even a junior programmer with some common sense already knows most of the "enlightened" observations.

There are some very interesting nuggets in there, but as others have mentioned, most of them are simple common sense or of no use at all.
I bought it mostly because of the good reviews, however I'm quite disappointed with the book.

If you are in software development or architecture you will most likely get a few quick knowledge gems from this. If you are a seasoned architect, you might get a few quick reminders.

The key here is quick. None of the "articles" are more than 2 pages long. This book is interesting in that it is 97 small articles which provides for a quick read. With the vast amount of technical books that I purchase (and mostly read) I liked the fact that I could get through this book in a reasonable amount of time and pickup some gems or reminders.

I read this from the beginning and basically read the title and the last 1 or 2 paragraphs of each article. If I found the article's summary intriguing I would invest in the entire article.

Some of the articles seem a bit contradictory but you should read the ones that make sense and disregard the rest. So was it worth the price? I believe so. Remember even the smallest amount of eduction/enlightenment is valuable.