4.0 out of 5 stars
97 things by 53 architects
Reviewed in the United States 🇺🇸 on March 29, 2009
There must be something not insignificant about the number "97", as a search for "97 things" retrieves multiple results here, and the follow-up books planned for this series (on project management, etc) have not yet been published. Quite honestly, this reviewer initially had low expectations for this book for various reasons, the least significant reason being the title. One related reason was use of the term "software architect", because this reviewer has both heard and read countless arguments on what "architect" actually means in this space. While some of the authors here allude to the definition of "architect", the one place the reader should probably expect an explanation on this matter is within an introductory chapter or preface. The preface, however, simply indicates that "software architects occupy a unique space in the world of IT. They are expected to know the technologies and software platforms on which their organizations run as well as the business that they serve...a great software architect needs to master both sides of the architect's coin: business and technology". But this statement does not even attempt to define architect. Instead, after reading this book the reader will likely leave with an understanding of a broad range of architect responsibilities communicated by dozens of different architects with varying levels of experience across numerous business industries. In the mind of this reviewer, this aspect might be one of the greatest strengths of this book because even though the 53 authors will probably generally agree on the definition of "architect", the degree to which their thoughts subtly differ on this aspect somewhat reflects what one will find in the workplace, especially when working as a consultant. The formula for this book just works. Some of the entries are admittedly rather light, but some of the entries reflect how much can be communicated in such a brief amount of space (all entries are limited to 2 pages in length). Some entries are probably more suited to software developers than architects, but it is a often a common expectation amongst software professionals that architects have a software development background, so some of this overlap is natural. A cursory review of the table of contents reveals the broad scope of topics presented by the authors, most of whom will probably not be recognized by the average reader. Some of this reviewer's favorite entries include: "Simplify Essential Complexity; Diminish Accidental Complexity", "Chances Are, Your Biggest Problem Isn't Technical", "Simplicity Before Generality, Use Before Reuse", "Architectural Tradeoffs", "Programming Is an Act of Design", "Context is King", "Learn from Architects of Buildings", "Challenge Assumptions - Especially Your Own", "Focus on Application Support and Maintenance", "Shortcuts Now Are Paid Back with Interest Later", "Pay Down Your Technical Debt", "Build Systems to Be Zuhanden", and "You Can't Future-Proof Solutions". This reviewer would like to see some of these entries spin-off into books of their own. By far "Pay Down Your Technical Debt" is the most creative of the lot and could be greatly expanded upon in a title such as that in risk management. Here is an exerpt: "So why the concern over making changes properly now versus later? It's because there's a hidden cost to making these quick and dirty fixes. For financial debts the hidden cost is called 'interest', and most anyone with a credit card knows how expensive just paying the interest on a debt can be. For technical debt, interest takes the form of instability in the system, and increased maintenance costs due to the hacked-in changes and lack of proper design, documentation, and/or tests. And, like financial interest, regular payments must be made until the original debt is repaid". Another reviewer for this book indicated that much of the material provided here is "common knowledge" (see my reply comment to reviewer "nobody"). As a consultant with a fair amount of project leadership, architecture, and development experience, this reviewer has found that this is certainly not the case. Well recommended especially for aspiring architects, although the conspicuous lack of explicit discussion on business and architectural qualities here is a bit of a drawback, so this reviewer refers the reader to "Software Architecture in Practice: 2nd Edition (SEI Series in Software Engineering)" by Len Bass, Paul Clements, and Rick Kazman (see my review for this book). Check out the 97-things wiki; the content of this book is free, and 38 additional entries that were not accepted for publication are also provided.
4 people found this helpful
