I picked up Fundamentals of software architecture last week. Overall the book is good as a starting point.
- It’ll help introduce and define the basic concepts.
- try to quantify them with simple equations.
- describe some of the famous ways software systems are organized
- and there is a small part of the book at the end that talks about the soft skills needed for an architect.
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 them.
In 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:
- Armchair architect: doesn’t care too much about the details
- Control Freak architect: controls every bit of the system and how it’s implemented
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 and even added some stock photos of 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 calculate some ratings that then you can use to decide how much control you can put on the team.
Back link to O’Reilly books ¶
The book is full of mentions of 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 few other examples are mentioned like “The Mythical Man-Month”.
Written by two authors and feels like so ¶
The book is written by two authors and feels exactly like that. Some parts are humble and show skepticism. like mentioning that it depends on the situation or the requirements. Other parts especially the ones that mention team activities are very assertive and sound like stating facts.
Black and white print wasn’t considered ¶
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?
Generally ¶
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 this point enough.
Here is how I see it:
- People got together and built software
- The software is getting bigger
- They have to come up with rules and guidelines to enforce consistency and other benefits
- The end up in long transitions from the current state to another better and consistent state
- Some patterns emerge between different people doing that
- We notice that and write books about it like this one.
The problem when the flow goes the other way around:
- Developers read the book as if it’s a holy scripture
- Developers like one of the organizations in the book
- Developers want to cast the current system they work on to this specific organization/pattern
- We end up in a holy war between different people with different opinions and preferences
So It’s important to look at this kind of book with skepticism and use it for what it’s written for:
- Documenting what others are doing in an organized way
- Getting some lessons learned from other situations
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 is not a unit by itself. but can be broken down, mixed, and combined with other patterns to build the goal system.