Architecture & design · Book notes
Fundamentals of Software Architecture: is it all still trade-offs?
The second edition adds five new chapters and grows from about 450 to almost 600 pages, but the First Law hasn't changed.. so what did?
A book whose first law is that every architecture choice has a cost got a new edition, about 5 years after the first. The authors describe it as close to a rewrite. Fundamentals of Software Architecture 2nd edition by Mark Richards & Neal Ford (O’Reilly, March 2025) grows from ~450 pages to almost 600. If the core law hasn’t changed, what has changed in the last 5 years to warrant five new chapters?
The book itself is recurring at the beginning of the common path. When people ask questions about the journey from developer to architect on r/softwarearchitecture, replies often mention Fundamentals first, followed by its sequel, Software Architecture: The Hard Parts. In a thread for beginners earlier this year, commenters emphasized the order, noting that The Hard Parts is the sequel, so Fundamentals should come first.
The central idea is the First Law: “Everything in software architecture is a trade-off.” A corollary is that if something doesn’t seem to be a trade-off, it’s because you haven’t identified the trade-off yet. The goal is then to find the least worst architecture for the few characteristics the system must excel at, and the early chapters on architecture characteristics spend a lot of time defining those characteristics. The 2nd edition adds a Third Law: most architecture decisions aren’t binary choices but lie on a spectrum between two extremes.
The new chapters are about how architecture rarely stands on its own. In a Thoughtworks podcast about the new material, Richards talks about how the real goal is to align architecture with what’s around it. Chapter 26, Architectural Intersections, talks about data, infrastructure, team topologies, and generative AI. The modular monolith gets its own chapter (11), and Ford talks about how this fills a gap in the original that was opened up by a changed ecosystem. In the same podcast, Ford describes a measure of friction between teams: count the merge conflicts an enabling team pushes into a stream-aligned team (more conflicts = more imposition on the other).
Discussion pushes back on the over-neat generalizing. Each style chapter gives 1-5 stars for each characteristic.. a review of the second edition published this month points out that microkernel can have poor or excellent maintainability, so a single rating doesn’t say much. Critiques of the 1st edition made a similar point years ago: a book that preaches context shouldn’t make sweeping claims. The sharpest disagreement is on AI. The book says LLMs lack the context and wisdom to weigh architecture trade-offs. The reviewer says that view will date fast.. AI tools are already useful for researching trade-offs, and the book gives no credit for that.
That’s where the disagreement comes in, and where I find it thought-provoking. In Always be curious I wrote that curiosity is why and building is how, and the book’s Second Law says why is more important than how. My curiosity led me to a career in cloud architecture. So if agents start doing more of the how, does the why (the trade-off written down and owned by someone) become most of the job? And if so, can a printed list of intersections keep up in a field moving this fast?