Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
architecture_books [2019/05/20 07:59]
mgunderloy
architecture_books [2019/05/20 08:00] (current)
mgunderloy
Line 4: Line 4:
   * [[https://​www.amazon.com/​Building-Evolutionary-Architectures-Support-Constant-ebook/​dp/​B075RR1XVG|Building Evolutionary Architectures]]:​ There are a lot of good points here about how to build large software systems that can withstand business change - though more of the points seem to be about what NOT to do. The actionable advice is a somewhat smaller piece of the book. The best part is the reminders that monoliths are not always bad; there are tradeoffs to be made. Ford has sweeping experience across many software trends, and it's nice to see microservices placed in the broader context. (Reviewed by Mike Gunderloy)   * [[https://​www.amazon.com/​Building-Evolutionary-Architectures-Support-Constant-ebook/​dp/​B075RR1XVG|Building Evolutionary Architectures]]:​ There are a lot of good points here about how to build large software systems that can withstand business change - though more of the points seem to be about what NOT to do. The actionable advice is a somewhat smaller piece of the book. The best part is the reminders that monoliths are not always bad; there are tradeoffs to be made. Ford has sweeping experience across many software trends, and it's nice to see microservices placed in the broader context. (Reviewed by Mike Gunderloy)
   * [[https://​www.amazon.com/​Building-Maintainable-Software-Java-Future-Proof-dp-1491953527/​dp/​1491953527|Building Maintainable Software]]   * [[https://​www.amazon.com/​Building-Maintainable-Software-Java-Future-Proof-dp-1491953527/​dp/​1491953527|Building Maintainable Software]]
-  * [[https://​pragprog.com/​book/​mkdsa/​design-it|Design It!]]+  * [[https://​pragprog.com/​book/​mkdsa/​design-it|Design It!]]: I enjoyed this introduction to software architecture,​ while recognizing that it's clearly one architect'​s view and that there are a lot of conflicting definitions in the field. This one at least was refreshingly close to the software design activities I already know from a career of programming,​ rather than being an "​enterprisey"​ muddle of vague generalities. (Reviewed by Mike Gunderloy)
   * [[https://​www.amazon.com/​Guerrilla-Capacity-Planning-Tactical-Applications/​dp/​3540261389|Guerilla Capacity Planning]]: An introduction to capacity planning in a land of fast change and imperfect information - though note that for Gunther "​fast"​ is a 3-month planning horizon, so it's hard to integrate this into the agile world. Focuses mainly on basic scalability laws, the difference between the parallelizable portion of the work and the rest, and shows applications in a variety of areas from program decomposition to internet scaling. Lots of math interspersed with smartass comments, the latter helpfully collected in an appendix so you don't have to wade through the math. (Reviewed by Mike Gunderloy)   * [[https://​www.amazon.com/​Guerrilla-Capacity-Planning-Tactical-Applications/​dp/​3540261389|Guerilla Capacity Planning]]: An introduction to capacity planning in a land of fast change and imperfect information - though note that for Gunther "​fast"​ is a 3-month planning horizon, so it's hard to integrate this into the agile world. Focuses mainly on basic scalability laws, the difference between the parallelizable portion of the work and the rest, and shows applications in a variety of areas from program decomposition to internet scaling. Lots of math interspersed with smartass comments, the latter helpfully collected in an appendix so you don't have to wade through the math. (Reviewed by Mike Gunderloy)
   * [[https://​www.amazon.com/​Just-Enough-Software-Architecture-Risk-Driven/​dp/​0984618104|Just Enough Software Architecture]]:​ A good introduction to the practice of software architecture for any reasonably-seasoned developer. The key takeaway here, and a point that Fairbanks hammers on early and often, is that the amount of modeling you should do is proportional to risk. There are no points for endless reams of documentation that no one ever reads in pursuit of "​completeness."​ He uses mostly (the simpler parts of) UML to demonstrate basic modeling concepts, and provides plenty of standard tools to get started. I don't know a better text for the budding architect. (Reviewed by Mike Gunderloy)   * [[https://​www.amazon.com/​Just-Enough-Software-Architecture-Risk-Driven/​dp/​0984618104|Just Enough Software Architecture]]:​ A good introduction to the practice of software architecture for any reasonably-seasoned developer. The key takeaway here, and a point that Fairbanks hammers on early and often, is that the amount of modeling you should do is proportional to risk. There are no points for endless reams of documentation that no one ever reads in pursuit of "​completeness."​ He uses mostly (the simpler parts of) UML to demonstrate basic modeling concepts, and provides plenty of standard tools to get started. I don't know a better text for the budding architect. (Reviewed by Mike Gunderloy)
  • architecture_books.txt
  • Last modified: 2019/05/20 08:00
  • by mgunderloy