Last year I attended the first edition of the GSAS conference. The speaker roster was impressive and included George Fairbanks. Was because of it that I decided to read Just Enough Software Architecture, a risk-driven approach.
The outcome of the conference didn't live up to my expectations. The tone felt distant and somehow settling a differentiation between architects and developers, some kind of elitist barrier (and here for sure I am failing to describe precisely my impressions due to lack of English vocabulary). That was weird because most of the talks, the one from Fairbanks included, were not explicitly suggesting it at all.
Turns out I got a similar impression from the book. There is valuable information on it, that's for sure, but the tone and a big part of it feel distant, maybe too academic, despite of Fairbanks efforts to provide meaningful examples and an informal tone.
The book is structured in two main blocks. The first one introduces Risk-Driven Software Architecture, its main highlight and indeed an interesting approach. How you should architect your application based on the risks and quality attributes you know it requires, doing the right trade-offs to find a balance between deliverability and engineering. For instance, do not build an astonishingly scalable system if none of your quality attributes is performance. The way Fairbanks introduces this technique is enjoyable and well-illustrated, with solid examples for all of the standpoints.
The second block, though, is composed of thoroug descriptions of ways of representing models of the architecture, at different levels and with different techniques. This translates to, and I know I am oversimplifying here, diagrams.
Almost two-thirds of the book revolves around levels of detail, types of architecture representations, and the relations between them. The amount of theory and detail is noticeable and it is hard to relate big chunks of content to what I currently need as a software developer ( which might mean this disappointment is caused by a mix of expectations and momentum in my career). It took me a lot of time to finish the book because of the low engagement with this second block, especially after a first one way more practical and concise.
Coming back to the conference perception, there is good stuff in the book and some things I will definitely take into account in my current and future projects. But at the same time, there is something hard to describe about it that made the reading not satisfactory. A contradiction between an approach to architecture encouraging doing just the necessary, and a tour about theoretical aspects of model representations that feel like way more than the necessary.
A first part that relates to software developers and a second part that relates to architects.
Top comments (3)
Hi Carlos,
Thanks for taking the time to review the book. I agree with your overall assessment. When I wrote it, I was thinking that some people will just skim the intro, others will get a few chapters in, and even fewer will make it to the end. You have perseverance! I'm glad that the intro and first section were things you found relevant, even if the last section didn't help.
Software development is an interesting field because the people who are doing the hands-on work are the same ones who are doing the big picture thinking. In other fields, those are often separated activities, for better or worse. Most software we write is similar to what we wrote yesterday, so you can skip the big picture thinking. Once you are in unfamiliar territory, however, I think you will end up thinking about concepts that are covered in the end of the book -- the diagrams and abstractions. Most other engineering fields have some split between abstractions (electrical current, mechanical stresses, etc) and what's relevant when you are doing the work with your hands.
Since writing the book, I've stayed interested in the abstractions, but I'm trying to make them relevant to daily software development. That's what my talk at GSAS was about. You might also like Simon Brown's work, as he has done a great job of connecting design ideas with daily coding -- much less distant and less academic.
Cheers,
-George
To be fair, I've learned to appreciate this book more and more since I read it.
Hi George,
That's a good point, and it is something I thought about several times while reading the book but failed to mention in the review: the examples provided cover several types of software systems, not only enterprise web applications that are the ones I work and have experience with. Probably my narrowed scope influenced my overall perception of the book. Sounds reasonable that the accurate model representations it describes are more relevant for applications like a car driving system or a factory robot software than for the classic 3-tier web application (and I'm not implying they are irrelevant in such applications).
Thanks for your comment, I wasn't expecting feedback that close to the "core" :)