- Shopping Bag ( 0 items )
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 ...
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:
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.
PrefaceChapter 1: Don't Put Your Resume Ahead of the RequirementsChapter 2: Simplify Essential Complexity; Diminish Accidental ComplexityChapter 3: Chances Are, Your Biggest Problem Isn't TechnicalChapter 4: Communication Is King; Clarity and Leadership, Its Humble ServantsChapter 5: Application Architecture Determines Application PerformanceChapter 6: Seek the Value in Requested CapabilitiesChapter 7: Stand Up!Chapter 8: Everything Will Ultimately FailChapter 9: You're Negotiating More Often Than You ThinkChapter 10: QuantifyChapter 11: One Line of Working Code Is Worth 500 of SpecificationChapter 12: There Is No One-Size-Fits-All SolutionChapter 13: It's Never Too Early to Think About PerformanceChapter 14: Architecting Is About BalancingChapter 15: Commit-and-Run Is a CrimeChapter 16: There Can Be More Than OneChapter 17: Business DrivesChapter 18: Simplicity Before Generality, Use Before ReuseChapter 19: Architects Must Be Hands OnChapter 20: Continuously IntegrateChapter 21: Avoid Scheduling FailuresChapter 22: Architectural TradeoffsChapter 23: Database As a FortressChapter 24: Use Uncertainty As a DriverChapter 25: Warning: Problems in Mirror May Be Larger Than They AppearChapter 26: Reuse Is About People and Education, Not Just ArchitectureChapter 27: There Is No 'I' in ArchitectureChapter 28: Get the 1,000-Foot ViewChapter 29: Try Before ChoosingChapter 30: Understand the Business DomainChapter 31: Programming Is an Act of Design Chapter 32: Give Developers AutonomyChapter 33: Time Changes EverythingChapter 34: "Software Architect" Has Only Lowercase a's; Deal with ItChapter 35: Scope Is the Enemy of SuccessChapter 36: Value Stewardship Over ShowmanshipChapter 37: Software Architecture Has Ethical ConsequencesChapter 38: Skyscrapers Aren't ScalableChapter 39: Heterogeneity WinsChapter 40: It's All About PerformanceChapter 41: Engineer in the White SpacesChapter 42: Talk the TalkChapter 43: Context Is KingChapter 44: Dwarves, Elves, Wizards, and KingsChapter 45: Learn from Architects of BuildingsChapter 46: Fight RepetitionChapter 47: Welcome to the Real WorldChapter 48: Don't Control, but ObserveChapter 49: Janus the ArchitectChapter 50: Architects' Focus Is on the Boundaries and InterfacesChapter 51: Empower DevelopersChapter 52: Record Your RationaleChapter 53: Challenge Assumptions—Especially Your OwnChapter 54: Share Your Knowledge and ExperiencesChapter 55: Pattern PathologyChapter 56: Don't Stretch the Architecture MetaphorsChapter 57: Focus on Application Support and MaintenanceChapter 58: Prepare to Pick TwoChapter 59: Prefer Principles, Axioms, and Analogies to Opinion and TasteChapter 60: Start with a Walking SkeletonChapter 61: It Is All About The DataChapter 62: Make Sure the Simple Stuff Is SimpleChapter 63: Before Anything, an Architect Is a DeveloperChapter 64: The ROI VariableChapter 65: Your System Is Legacy; Design for ItChapter 66: If There Is Only One Solution, Get a Second OpinionChapter 67: Understand the Impact of ChangeChapter 68: You Have to Understand Hardware, TooChapter 69: Shortcuts Now Are Paid Back with Interest LaterChapter 70: "Perfect" Is the Enemy of "Good Enough"Chapter 71: Avoid "Good Ideas"Chapter 72: Great Content Creates Great SystemsChapter 73: The Business Versus the Angry ArchitectChapter 74: Stretch Key Dimensions to See What BreaksChapter 75: If You Design It, You Should Be Able to Code ItChapter 76: A Rose by Any Other Name Will End Up As a CabbageChapter 77: Stable Problems Get High-Quality SolutionsChapter 78: It Takes DiligenceChapter 79: Take Responsibility for Your DecisionsChapter 80: Don't Be CleverChapter 81: Choose Your Weapons Carefully, Relinquish Them ReluctantlyChapter 82: Your Customer Is Not Your CustomerChapter 83: It Will Never Look Like ThatChapter 84: Choose Frameworks That Play Well with OthersChapter 85: Make a Strong Business CaseChapter 86: Control the Data, Not Just the CodeChapter 87: Pay Down Your Technical DebtChapter 88: Don't Be a Problem SolverChapter 89: Build Systems to Be ZuhandenChapter 90: Find and Retain Passionate Problem SolversChapter 91: Software Doesn't Really ExistChapter 92: Learn a New LanguageChapter 93: You Can't Future-Proof SolutionsChapter 94: The User Acceptance ProblemChapter 95: The Importance of ConsomméChapter 96: For the End User, the Interface Is the SystemChapter 97: Great Software Is Not Built, It Is GrownColophon
Posted March 26, 2009
97 Things Every Software Architect Should Know is a book about things which are obvious and every software architect should know, remember and employ. The problem is that most things you can find inside the book are easily forgotten, underestimated and usually not implemented during day-to-day work.
The book consists of 97 short essays. Each of them deals with a vital problem software architects often have to face. Although there are great number of brilliant stories in the book I especially like the one titled: You're Negotiating More Often Than You Think, which is about a project sponsor wanting to cut down expenses. Does it sound familiar to you? Do you know what to do when it happens? The book is a collective work which makes it even more valuable.
Every day in the morning I start my work reading 1-3 essays to keep good practices in my memory and not forget management pitfalls lying in wait for me round the corner. I believe it helps me to become a better software architect. This book is a great and rare opportunity to learn from real experts in the field.
1 out of 1 people found this review helpful.Was this review helpful? Yes NoThank you for your feedback. Report this reviewThank you, this review has been flagged.
Posted June 18, 2009
After reading this book, I've made a firm decision that I do not want to be an architect. My decision is not because of the book however.
Within the pages of this book, you will get some great insight into the real world of being a software architect. Some of the tips are so obvious that you smack yourself for not already just knowing.
Though I am not an architect, I found some of the tips such as "Perfect is the enemy of good enough" and a few others that relieved some of the weight off of my shoulders. If top notch architects tell me that good enough is good enough then I can stop struggling for perfection.
This book is going on my shelf, but I have no doubt that I will pick it back up in 6 months and read it again.
Posted November 25, 2010
No text was provided for this review.
Posted March 7, 2011
No text was provided for this review.
Posted July 26, 2011
No text was provided for this review.