Cover image for 97 Things Every Software Architect Should Know

97 Things Every Software Architect Should Know

Author Richard Monson-Haefel
Release Date: 2009/02/01
ISBN: 9780596800611
Topic:
0%
103
Chapters
0-1
Hours read
0k
Total Words
    Start Reading Now    
       Add to Wishlist       
View table of contents

Book Description

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.

Table of Contents

  1. Preface
    1. Permissions
    2. How to Contact Us
    3. Safari® Books Online
    4. Acknowledgments
  2. 1. Don’t Put Your Resume Ahead of the Requirements
  3. 2. Simplify Essential Complexity; Diminish Accidental Complexity
  4. 3. Chances Are, Your Biggest Problem Isn’t Technical
  5. 4. Communication Is King; Clarity and Leadership, Its Humble Servants
  6. 5. Application Architecture Determines Application Performance
  7. 6. Seek the Value in Requested Capabilities
  8. 7. Stand Up!
  9. 8. Everything Will Ultimately Fail
  10. 9. You’re Negotiating More Often Than You Think
  11. 10. Quantify
  12. 11. One Line of Working Code Is Worth 500 of Specification
  13. 12. There Is No One-Size-Fits-All Solution
  14. 13. It’s Never Too Early to Think About Performance
  15. 14. Architecting Is About Balancing
    1.  
      1. Balance Stakeholders’ Interests with Technical Requirements
  16. 15. Commit-and-Run Is a Crime
  17. 16. There Can Be More Than One
  18. 17. Business Drives
  19. 18. Simplicity Before Generality, Use Before Reuse
  20. 19. Architects Must Be Hands On
  21. 20. Continuously Integrate
  22. 21. Avoid Scheduling Failures
  23. 22. Architectural Tradeoffs
  24. 23. Database As a Fortress
  25. 24. Use Uncertainty As a Driver
  26. 25. Warning: Problems in Mirror May Be Larger Than They Appear
  27. 26. Reuse Is About People and Education, Not Just Architecture
    1.  
      1. Know It’s There
      2. Know How to Use It
      3. Are Convinced That It’s Better Than Doing It Themselves
  28. 27. There Is No ‘I’ in Architecture
  29. 28. Get the 1,000-Foot View
  30. 29. Try Before Choosing
  31. 30. Understand the Business Domain
  32. 31. Programming Is an Act of Design
  33. 32. Give Developers Autonomy
  34. 33. Time Changes Everything
    1.  
      1. Pick a Worthy Challenge
      2. Simple Rules
      3. Be Happy with That Old Stuff
  35. 34. “Software Architect” Has Only Lowercase a’s; Deal with It
  36. 35. Scope Is the Enemy of Success
  37. 36. Value Stewardship Over Showmanship
  38. 37. Software Architecture Has Ethical Consequences
  39. 38. Skyscrapers Aren’t Scalable
  40. 39. Heterogeneity Wins
  41. 40. It’s All About Performance
  42. 41. Engineer in the White Spaces
  43. 42. Talk the Talk
  44. 43. Context Is King
  45. 44. Dwarves, Elves, Wizards, and Kings
  46. 45. Learn from Architects of Buildings
  47. 46. Fight Repetition
  48. 47. Welcome to the Real World
  49. 48. Don’t Control, but Observe
  50. 49. Janus the Architect
  51. 50. Architects’ Focus Is on the Boundaries and Interfaces
  52. 51. Empower Developers
  53. 52. Record Your Rationale
  54. 53. Challenge Assumptions—Especially Your Own
  55. 54. Share Your Knowledge and Experiences
  56. 55. Pattern Pathology
  57. 56. Don’t Stretch the Architecture Metaphors
  58. 57. Focus on Application Support and Maintenance
  59. 58. Prepare to Pick Two
  60. 59. Prefer Principles, Axioms, and Analogies to Opinion and Taste
  61. 60. Start with a Walking Skeleton
  62. 61. It Is All About The Data
  63. 62. Make Sure the Simple Stuff Is Simple
  64. 63. Before Anything, an Architect Is a Developer
  65. 64. The ROI Variable
  66. 65. Your System Is Legacy; Design for It
  67. 66. If There Is Only One Solution, Get a Second Opinion
  68. 67. Understand the Impact of Change
  69. 68. You Have to Understand Hardware, Too
  70. 69. Shortcuts Now Are Paid Back with Interest Later
  71. 70. “Perfect” Is the Enemy of “Good Enough”
  72. 71. Avoid “Good Ideas”
  73. 72. Great Content Creates Great Systems
  74. 73. The Business Versus the Angry Architect
  75. 74. Stretch Key Dimensions to See What Breaks
  76. 75. If You Design It, You Should Be Able to Code It
  77. 76. A Rose by Any Other Name Will End Up As a Cabbage
  78. 77. Stable Problems Get High-Quality Solutions
  79. 78. It Takes Diligence
  80. 79. Take Responsibility for Your Decisions
  81. 80. Don’t Be Clever
  82. 81. Choose Your Weapons Carefully, Relinquish Them Reluctantly
  83. 82. Your Customer Is Not Your Customer
  84. 83. It Will Never Look Like That
  85. 84. Choose Frameworks That Play Well with Others
  86. 85. Make a Strong Business Case
  87. 86. Control the Data, Not Just the Code
  88. 87. Pay Down Your Technical Debt
  89. 88. Don’t Be a Problem Solver
  90. 89. Build Systems to Be Zuhanden
  91. 90. Find and Retain Passionate Problem Solvers
  92. 91. Software Doesn’t Really Exist
  93. 92. Learn a New Language
  94. 93. You Can’t Future-Proof Solutions
    1.  
      1. Today’s Solution Is Tomorrow’s Problem
  95. 94. The User Acceptance Problem
  96. 95. The Importance of Consommé
  97. 96. For the End User, the Interface Is the System
  98. 97. Great Software Is Not Built, It Is Grown
  99. Index
  100. Colophon
  101. Copyright
3.145.2.184