97 Things Every Software Architect Should Know
In this truly unique technical book, today's leading software architects present valuable principles on key development issues that go way beyond technology. More than four dozen architects— including Neal Ford, Michael Nygard, and Bill de hOra—offer advice for communicating with stakeholders, eliminating complexity, empowering developers, and many more practical lessons they've learned from years of experience. Among the 97 principles in this book, you'll find useful advice such as: Don't Put Your Resume Ahead of the Requirements (Nitin Borwankar) Chances Are, Your Biggest Problem Isn't Technical (Mark Ramm) Communication Is King; Clarity and Leadership, Its Humble Servants (Mark Richards) Simplicity Before Generality, Use Before Reuse (Kevlin Henney) For the End User, the Interface Is the System (Vinayak Hegde) It's Never Too Early to Think About Performance (Rebecca Parsons)
To be successful as a software architect, you need to master both business and technology. This book tells you what top software architects think is important and how they approach a project. If you want to enhance your career, 97 Things Every Software Architect Should Know is essential reading.
Review By: C. David Moye
06/17/2010This book is a collection of roughly two-paged nuggets doled out by some of the industry's most well-respected software architects (or, for those that eschew that title, software engineers). It is a unique book in that instead of presenting a long treatise on the how to do software architecture in general, it shoots strategic gems at you, rapid-fire, in a format that even the most attention deprived individual can appreciate. And, being technology-independent, it reaches a wide range of practitioners.
The articles go beyond typical architectural precepts and into architectural inspiration (e.g., "Learn from Architects of Buildings" which, without direct reference, intimates the work of Christopher Alexander in his seminal works Notes on the Synthesis of Form and A Pattern Language). In addition, there is great focus on the "soft" skills required by good architects (see "Communication is King", "Stand Up!" and "Reuse is About People and Education"). Yet, this is not to say that every article is that way. "Database as a Fortress" and "If You Design It, You Should Be Able to Code It" are among the many pieces that hit home for the more hardcore readers.
While the title of the book suggests that it is primarily for architects and/or senior developers, a lot of different folks in a lot of different roles will benefit from reading even parts of it. Managers will gain a better understanding of the underlying issues of good software development and get a better handle on some of the reasons that their teams want to do things in certain ways. Better still, they may be able to push their teams to make sure the right set of problems is being considered. Software testers will get an idea of how the software being tested is constructed and be better able to craft test suites and test cases to flex the solutions they are testing—at the right joints.
All told, Richard Monson-Haefel did a great job editing a series of short essays authored by a well-respected audience of contributors into a single volume of work that will stand the test of time. This book deserves a place on your bookshelf.