15 wisdom pearls on Software Architecture from the AOSA book

Tweet about this on TwitterShare on FacebookBuffer this pageShare on RedditShare on LinkedInShare on Google+Email this to someone

I’ve just finished reading the book “The Architecture of Open Source Applications” (eds. Amy Brown and Greg Wilson ). in it, the authors of twenty-five open source applications explain how their software is structured, and why. What are each program’s major components? How do they interact? And what did their builders learn during their development? […] If you are a junior developer, and want to learn how your more experienced colleagues think, this book is the place to start. If you are an intermediate or senior developer, and want to see how your peers have solved hard design problems, this book can help you too.

I’ve learnt a lot reading the book. Reading ALL these “lessons learnt” really helps you to see architecture design with a different perspective. Let me just give you 15 of the many wisdom pearls on software architecture you’ll learn when you buy the book (sure you can also read it online but remember that all royalties from these sales will be donated to Amnesty International).

15 wisdom pearls on software architecture (in no particular order; enjoy!):

  1. The structure of a program […] clearly is not designed up front. It is something that develops over time. James Crook
  2. It’s difficult to think clearly about program architecture after code debugging begins. Margo Seltzer and Keith Bostic
  3. Two copies of any specific functionality in your code guarantees that one of them is incorrectly implemented. Margo Seltzer and Keith Bostic
  4. Developers are happier and more productive when using the tools they are most familiar with. By allowing developers to use their preferred tools, projects can take best advantage of their most important resource: the developer. Bill Hoffman and Kenneth Martin
  5. You don’t have to maintain backward compatibility with something that users don’t have access to. Bill Hoffman and Kenneth Martin
  6. The choice of architecture seems to canalize or direct development towards a particular set of features. C. Titus Brown and Rosangela Canino-koning
  7. API IS forever. A stable API is a contract between the client or API consumer and the provider. Kim Moir
  8. It is hardly ever worth it to spend a lot of time designing an application to be 100% future-proof. it is quite likely that a painstaking design phase will introduce complexities that
    you will never need because the scenarios you prepared for never happen. Emil Ivov

  9. A Package that enters the standard library has one foot in the grave. Tarek Ziadé
  10. Design principle. Accept that one programmer is finite. Eric Allman.
  11. Most features in the system were designed as direct response to user feedback. However,[…] being responsive to users does not necessarily mean doing exactly what they ask for. Juliana Freire, David Koop, Emanuele Santos, Carlos Scheidegger, Claudio Silva, and Huy T. Vo
  12. The near term future focuses more on managing the growth of the community as well as the software. Berk Geveci and Will Schroeder
  13. Scalability has very little to do with low-level performance but instead is a product of overall design. Chris Davis
  14. You can learn much more from closelyl studying actual failures than from theorizing about superior strategies. Chris Davis.
  15. Keeping replicas of your data on multiple machines consistent with one-another is hard. Adam Marcus

    If you want to take a look at my other reviewed books, check the list of MDD/MDA books , UML books ,and OCL books

    If you enjoyed this post you can subscribe TO this Software Modeling blog , TO the portal’s mailing list , follow me on twitter and/or participate in the forums . And if you really liked it help me pass it on to others by sharing the post using the links below. Don’t forget TO CHECK our consulting AND code-generation services either!

    Tweet about this on TwitterShare on FacebookBuffer this pageShare on RedditShare on LinkedInShare on Google+Email this to someone
Comments

Reply

Your email address will not be published. Required fields are marked *