I picked up Fundamentals of software architecture last week. Overall the book is good as a starting point.
Sometimes during reading it I had to scan the paragraphs to see if there is something important in it. As sometimes there is a tendency to expand on trivial points and even provide examples and reference tables to it.
One section in the soft skill the authors were talking about “How much control the architect should exert on a team”. then they named two sides of the behavior:
And the goal is to be in the middle of these two examples and swing back and forth depending on the team size and knowledge…etc
But they went too far in the description and examples even added some stock photos for an angry man pointing to you and another lazy stock photo guy on a chair. then went to quantify teams need for control in a table and how to calculate some rating that then you can use it to decide how much control you can put on the team.
The book is full of mentions to other books in the industry mainly O’Reilly published books. It feels like when you visit a blog post now and it’s full of links to other posts on the same website just for the sake of SEO. very view other examples are mentions like “The Mythical Man-Month”.
The books is written by two authors and feels exactly like that. Some parts are humble and shows skepticism. like mentioning that it depends on the situation or the requirements. Other parts especially the ones the mentions team activities are very assertive and sounds like stating facts.
In some cases the books was describing diagrams with different colors. But the book is printed in black and white. So it seems the authors didn’t consider this fact while writing this part of the book?
The book is good. It’s one of these books that are documenting what the rest of the industry is doing and it’s important to have such books to have a well-documented history of our industry. But I can’t stress on this point enough.
Here is how I see it:
The problem when the flow goes the other way around:
So It’s important to look at this kind of books with skepticism and use it for what it’s written for:
And we have to know that every system is very different. the organization structure is different and the software goals and required characteristics are different. So each of these proposed solutions are not a unit by itself. but can be broken down, mixed and combined with other patterns to build the goal system.