
Righting Software
by Juval Löwy · first published 2019
11mentions
4recommended by
9HN commenters
2020–2024first – last mentioned
44% recommend44% neutral11% critical
Affiliate links. As an Amazon Associate I earn from qualifying purchases.







You may wish to take a look at the book, Righting Software, by Juval Löwy. It is not specific to any particular application or language, but can be generally applied to different projects and systems. https://www.amazon.com/dp/0136524036
on “Becoming a Systems Architect” ↗…By Tests - Freeman & Pryce ("The Goose Book") * Modern Java in Action - Raoul-Gabriel Urma * Java Concurrency in Practice - Brian Goetz * Grokking Algorithms - Aditya Y. Bhargava Architecture: * Righting Software - Juval Lowy * Release It! - Michael Nygard * Site Reliability Engineering - Beyer, et al. ("The SRE Book”) * Domain Driven Design - Eric Evans * Introduction to Permaculture - Bill Mollison and Mia…
on “Theory-building and why employee churn is lethal to software companies” ↗I suggest looking into: https://www.amazon.com/Righting-Software-Juval-L%C3%B6wy/dp/... It's very unorthodox, but cuts through a lot of the bullshit.
on “Ask HN: Best books on managing software complexity?” ↗Have you read "Righting Software" by Juval Lowy? You might really enjoy it based on your feedback above and here. There is a project design aspect that goes into this kind of planning (or at least reminds me of what you wrote).
on “Show HN: I built my own PM tool after trying Trello, Asana, ClickUp, etc.” ↗A Philosophy of Software Design https://web.stanford.edu/~ouster/cgi-bin/book.php Righting Software https://rightingsoftware.org/
on “Ask HN: Reading material on how to be a better software engineer?” ↗…teaching a workshop in September and bought a copy for every attendee because I believe it is that important for people to be exposed to his ideas and how he approaches things. I was also impressed with "Righting Software" and the premise of volatility based decomposition but it is not nearly as approachable as Ousterhout's book.
on “A brief interview with Tcl creator John Ousterhout (2023)” ↗…Microservices have their place. So do monolithic, centralized services. Using both in the same system is certainly not a sin, can can certainly be correct. I'm currently reading through Juval Lowy's latest book, Righting Software. Juval is widely credited as one of the pioneers of microservices [1], and he states in the book that even he doesn't appreciate the term. He illustrates his point by comparing the small, eight-inch water…
on “Questions to ask before adopting microservices” ↗Tangentially related, has anyone tried to implement the ideas described in Juval Lowy's new book, "Righting Software" (https://www.amazon.com/Righting-Software-Juval-L%C3%B6wy-ebo...)? His methodology of project management seems much more systematic than week-by-week sprint planning.
on “Agile's early evangelists wouldn't mind watching Agile die” ↗…finding a lot to agree with and some new ideas to think about. Sorry to hijack the discussion slightly but while we're on the subject of software design books, I wondered if anyone had any thoughts about 'Righting Software' (Juval Lowy)? Particularly the first few chapters about software architecture.
on “Book Review: A Philosophy of Software Design (2020)” ↗…how they ought to fit together. I've found some real success in approaches that subject the design of the software up front to the stresses of potential change, like those given by Juval Lowy (IDesign, Righting Software) and Barry O'Reilly (Black Tulip, Residuality Theory). And to subject a design to stress, of course first you have to do some system design! If you're not at the stage of being able to put together a…
on “That won't scale Or present cost vs. future value” ↗…controversial takes are that the whole series of Domain Driven Design books are pretty poor. I've seen several teams fall into a mud pit of endless meetings arguing about entities vs repositories. Same thing with Righting Software. The books are all filled with vague statements so everyone just spends all this time debating what they mean. It turns teams from thinking critically into religious bickering. Same for all the design…
on “Just Enough Software Architecture (2010)” ↗