97 Things Every Software Architect Should Know: Collective Wisdom from the Experts

Front Cover
"O'Reilly Media, Inc.", Feb 5, 2009 - Computers - 222 pages
3 Reviews

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.

 

What people are saying - Write a review

User Review - Flag as inappropriate

"97 Things Every Software Architect Should Know" is a new title from O’Reilly. It is edited by Richard Monson-Haefel, you might know him from "Enterprise JavaBeans", "Java Message Services" or "J2EE Web Services". This time, his book is a set of guidelines collected from about 50 experienced software architects. Among them you can find Google, Microsoft, Sun Microsystems employees, authors of books, freelancers etc. My favorites are:
- Michael Nygard – "wrote: Release It! Design and Deploy Production-Ready Software (Pragmatic Bookshelf)…"
- Craig Russell – "is a practicing software architect specializing in object persistence and distributed systems. He currently works as a senior staff engineer at Sun Microsystems."
- Mark Ramm – "is BDFL for TurboGears 2, a python enthusiast, and a generally crazy dude … "
Each advice is maximum two pages long, with author's short biography note at the end. All 97 advices are based on real life experience. Often, there are short stories showing why is it important or how it works. There is even story about the design of F16 jet fighter aircraft! It really helps to remember information.
I like this book because it is very pragmatic. In my opinion the subtitle describes it in a perfect way, which is "Collective Wisdom from the Experts". All advices are based on many years of experience and in my opinion all of them are truly important. Some of them are very obvious, but it is good to read about it one more time. Each chapter is very short so you do not need a lot of time to read it. It is a perfect read for a bus or short break. My favorite hints are:
- "One Line of Working Code is Worth 500 of specification"
- "Commit-and-Run is a Crime"
- "Avoid Scheduling Failures"
If you are looking for a book which says about architecture problems and gives you "3000-Foot view" this one is for you. I didn’t like that high level problems, a lot of them should be dedicated to team leaders. I was looking for a book focused on design patterns, best practices and advices for software design, and this one is more about how to lead a group of people. For example, one of these advices says that you are supposed to stand up while talking to developers to increase effectiveness of your communication. I agree, it is important, but it is a book about software architecture not interpersonal communication. Read the titles of the chapters before buying it. It is probably my problem, because I am not an architect, I am rather software developer/designer.
I recommend "97 Things Every Software Architect Should Know" to team leaders and high level architects. For those who would like to summarize their knowledge. It is not a tutorial or "how to" book. I don't recommend it to software developers and designers, you might be bored.
 

Contents

Empower Developers
102
Record Your Rationale
104
Challenge AssumptionsEspecially Your Own
106
Share Your Knowledge and Experiences
108
Pattern Pathology
110
Dont Stretch the Architecture Metaphors
112
Focus on Application Support and Maintenance
114
Prepare to Pick Two
116

Youre Negotiating More Often Than You Think
18
Quantify
20
One Line of Working Code Is Worth 500 of Specification
22
There Is No OneSizeFitsAll Solution
24
Its Never Too Early to Think About Performance
26
Architecting Is About Balancing
28
CommitandRun Is a Crime
30
There Can Be More Than One
32
Business Drives
34
Simplicity Before Generality Use Before Reuse
36
Architects Must Be Hands On
38
Continuously Integrate
40
Avoid Scheduling Failures
42
Architectural Tradeoffs
44
Database As a Fortress
46
Use Uncertainty As a Driver
48
Problems in Mirror May Be Larger Than They Appear
50
Reuse Is About People and Education Not Just Architecture
52
There Is No I in Architecture
54
Get the 1000Foot View
56
Try Before Choosing
58
Understand the Business Domain
60
Programming Is an Act of Design
62
Give Developers Autonomy
64
Time Changes Everything
66
Software Architect Has Only Lowercase as Deal with It
68
Scope Is the Enemy of Success
70
Value Stewardship Over Showmanship
72
Software Architecture Has Ethical Consequences
74
Skyscrapers Arent Scalable
76
Heterogeneity Wins
78
Its All About Performance
80
Engineer in the White Spaces
82
Talk the Talk
84
Context Is King
86
Dwarves Elves Wizards and Kings
88
Learn from Architects of Buildings
90
Fight Repetition
92
Welcome to the Real World
94
Dont Control but Observe
96
Janus the Architect
98
Architects Focus Is on the Boundaries and Interfaces
100
Prefer Principles Axioms and Analogies to Opinion and Taste
118
Start with a Walking Skeleton
120
It Is All About The Data
122
Make Sure the Simple Stuff Is Simple
124
Before Anything an Architect Is a Developer
126
The ROI Variable
128
Your System Is Legacy Design for It
130
If There Is Only One Solution Get a Second Opinion
132
Understand the Impact of Change
134
You Have to Understand Hardware Too
136
Shortcuts Now Are Paid Back with Interest Later
138
Perfect Is the Enemy of Good Enough
140
Avoid Good Ideas
142
Great Content Creates Great Systems
144
The Business Versus the Angry Architect
146
Stretch Key Dimensions to See What Breaks
148
If You Design It You Should Be Able to Code It
150
A Rose by Any Other Name Will End Up As a Cabbage
152
Stable Problems Get HighQuality Solutions
154
It Takes Diligence
156
Take Responsibility for Your Decisions
158
Dont Be Clever
160
Choose Your Weapons Carefully Relinquish Them Reluctantly
162
Your Customer Is Not Your Customer
164
It Will Never Look Like That
166
Choose Frameworks That Play Well with Others
168
Make a Strong Business Case
170
Control the Data Not Just the Code
172
Pay Down Your Technical Debt
174
Dont Be a Problem Solver
176
Build Systems to Be Zuhanden
178
Find and Retain Passionate Problem Solvers
180
Software Doesnt Really Exist
182
Learn a New Language
184
You Cant FutureProof Solutions
186
The User Acceptance Problem
188
The Importance of Consommé
190
For the End User the Interface Is the System
192
Great Software Is Not Built It Is Grown
194
Index
196
Copyright

Other editions - View all

Common terms and phrases

About the author (2009)

Richard Monson-Haefel, an independent software developer, coauthored all five editions of Enterprise JavaBeans and Java Message Service (all O'Reilly). He's a software architect specializing in multi-touch interfaces and a leading expert on enterprise computing. More detail on his work and writings can be found at www.monson-haefel.com.

Bibliographic information