97 Things Every Software Architect Should Know: Collective Wisdom from the ExpertsIn 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:
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. |
Contents
| 2 | |
| 4 | |
| 6 | |
Communication Is King Clarity and Leadership Its Humble Servants | 8 |
Application Architecture Determines Application Performance | 10 |
Seek the Value in Requested Capabilities | 12 |
Stand Up | 14 |
Everything Will Ultimately Fail | 16 |
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 |
| 196 | |
Other editions - View all
Common terms and phrases
97 Things accidental complexity Agile anti-patterns application application’s approach archi Architect Should Know architectural decisions Author bio available automated Barry Hawkins bugs build business domain Chad LaVigne communication components constraints consultant context cost create data model database design patterns development team difficult documentation effective ensure enterprise enterprise architecture Enterprise JavaBeans essential complexity evolve example experience failure framework functionality goal hardware ideas implement important infrastructure integration J2EE Keith Braithwaite Kevlin Henney lead look means ment messaging Michael Nygard O’Reilly one’s open source performance practices problem production Professional programming Rebecca Parsons requirements response server service-oriented architecture simple software architect software development software engineer software industry software project solution solving source code specific stakeholders success sure technical tect tecture testing there’s Things Every Software ThoughtWorks tion today’s tradeoffs trying understand user interface