Righting Software

by Juval Lowy

Right Your Software and Transform Your Career

Righting Software presents the proven, structured, and highly engineered approach to software design that renowned architect Juval Löwy has practiced and taught around the world. Although companies of every kind have successfully implemented his original design ideas across hundreds of systems, these insights have never before appeared in print.

Based on first principles in software engineering and a comprehensive set of matching tools and techniques, Löwy’s methodology integrates system design and project design. First, he describes the primary area where many software architects fail and shows how to decompose a system into smaller building blocks or services, based on volatility. Next, he shows how to flow an effective project design from the system design; how to accurately calculate the project duration, cost, and risk; and how to devise multiple execution options.

The method and principles in Righting Software apply regardless of your project and company size, technology, platform, or industry. Löwy starts the reader on a journey that addresses the critical challenges of software development today by righting software systems and projects as well as careers—and possibly the software industry as a whole. Software professionals, architects, project leads, or managers at any stage of their career will benefit greatly from this book, which provides guidance and knowledge that would otherwise take decades and many projects to acquire.
Register your book for convenient access to downloads, updates, and/or corrections as they become available. See inside book for details.

Genres: Software, Programming, Technology, Technical, Architecture, Computer Science, Engineering

480 pages, Kindle Edition

Published November 27, 2019

Reviews

[Mark Seemann · Rating 2 out of 5]

I've always liked hard science fiction - the kind that starts with a premise and then proceeds to extrapolate in great technical details what the consequences would be.

Clearly, Neal Stephenson is a master of that sub-genre, with books like The Rise and Fall of D.O.D.O. (what would happen if a certain type of time travel was possible?) and Seveneves (what would happen if the Moon suddenly fell apart?).

The premise may be quite preposterous. Examples include Redshirts (what happens if the characters find out that they're 'expendables' in a Star Trek-like TV show?) and The First Fifteen Lives of Harry August (what happens if you get to live your life over and over?).

This one starts with the premise that it's possible to accurately estimate the tasks in a software development project. There's a few other fantastical elements as well, such as that it's possible to design software component interactions up-front, and that you don't need developers during a project's testing phase. I found that the combined effect challenged my suspension of disbelief.

Based on the premise, though, I found the second part titled Project Design fascinating. It put on display how, with accurate estimates, you can create a dependency graph for the project, which again enables you to detect its critical path. All activities not on the critical path can be assigned to developers based on float, which is a measure of how much that activity can tolerate delay before it becomes critical. That part is captivating, because a rich edifice is built on such shaky grounds.

There's another sub-genre of science fiction set in an alternate history instead of the future. Examples include The Man in the High Castle and The Difference Engine. I've never cared much for this sub-genre, as I find it more a gimmick than a fruitful premise.

This one is set in an alternative reality that seems to branch off from ours around 1994. This is a world where software is 'constructed' like houses. First an architect designs a plan, and then 'resources' 'construct' the software based on the architect's design.

Software is 'constructed' from the bottom up. People in this book start with logging components and database designs, then proceed to program abstract base classes, then 'managers' and 'engines', and finally user interfaces. Once everything's integrated, the project proceeds to the testing phase. Finally, perhaps 10 months after project start, the software is delivered to the customer or users.

This is a world where it seems that the inhabitants have never heard about outside-in development or continuous delivery. Where no reusable logging libraries or message bus frameworks exist. Where no-one has heard about the Dependency Inversion Principle - in fact, where no-one seems to be aware of software engineering literature from 1994 and forward. It's not explicitly stated, but it seems that the alternate history must be branching off somewhere around 1994.

Initially, the protagonist seems to be on a Don Quixote-like quest, but instead of tilting at windmills seems to have it out for something called functional decomposition. It wasn't really clear to me exactly what it was, or why it was so evil, but I think that it may have been a sort of shibboleth for cohesion. As Kent Beck put it:

Things that change at the same rate belong together. Things that change at different rates belong apart.

As the book progresses, however, this seems to be largely forgotten, and instead the design of a project takes up most of the narrative. This part was more interesting, although it was too long, and there were too many deus-ex-machina rescues.

[Sebastian Gebski]

No star rating, as it would be treated as a rating of "the Method", not the book itself (and this is not how GR are supposed to work).

RS presents "the Method" - Lowy's own method to design & build software in a stable, predictable, estimable way, with proper architecture, etc.
Both the book and the method are very opinionated and ... controversial. Mainly because they are built upon very "traditional", project-based, sequential approach. Lowy rejects such concepts as functionality-based decomposition, evolutionary building, etc.

The book consists of 2 parts: the 1st one is about designing "the product" and the 2nd one (much longer in fact) is about designing "the project" (the way to deliver the product). What I've found the most interesting in the 1st part was the idea of decomposing solution into parts based on their (assumed? guessed? expected?) volatility. I have to admit the idea resonates with me, be in practice it seems like ... well, guesswork. And the chapter with the sample solution didn't really change my mind. In addition, JL uses his own mental model ("engines, managers, ...") which is quite irritating as it feels like taken straight from 80s ...

The 2nd part (project one) is actually quite boring - plenty of formulas that do make sense in theory but are absolutely useless in practical, complex reality that can't be assessed with simple equations.

In the end - neither the book, nor the method are revolutionary or ground-breaking. Feel free to skip them.

[Jevgenij · Rating 2 out of 5]

A pretty weak book, with a very high-level system design part and very detailed, but still useless project management part. Here are some things that were wrong with the system design part (I just skimmed through the project management part after that):
- Too many real-world analogies (software is not the real world and it operates under different laws).
- Renaming commonly-known terms as if they are invented at IDesign (SRP, consistency)
- No code examples or even class diagrams.
- Repetitive.

[Johnny · Rating 1 out of 5]

The book description of Righting Software sounds like the perfect book for me. It combines so many things I am interested in that the combination of it must be great. Unfortunately, what the book delivers is anything but good.

It is not even 6 months after the release and this book already feels dated. It seems that every (re-) discovery the software development industry made in the last 20 years went unnoticed to the author. Continuous Integration? No need to do more than a smoke test for the integration once per day. Continuous Delivery? No need, then you only get features at the end of the project. A holistic approach to solving problems? Yes, but the architect is holistic enough – the team is just a resource that can be added or removed as you need. Fast feedback cycles? No need, the architect has everything planned and sliced the work to create the dependency graph that you as developer just need to follow.

Most/All design happens upfront, then build the software and test at the end - that sounds a lot like a waterfall to me. The author calls his method The Method, what is an early example on how he will use names of concepts throughout the book: When a concept has a name, the author will not bother to use it.

The unique selling point of this book is the decomposition of the project by volatility. Functional decomposition is evil, only splitting around volatility will help you to create a successful project (change the name and you are back at the old concept of Stable Dependencies Principle - A package should only depend upon packages that are more stable than it is). While many paragraphs where spend on why functional decomposition is bad and using volatility is so much better, software related examples on how to do that are missing. You get examples about furniture and buildings, but the concrete examples for software did not make it into the book. Given the importance this topic has for this book (everything else is built on this decomposition), I cannot see how anyone will be able to put The Method into action. If we ignore that part, we are left with Use Cases containing activity diagrams and a multi-layered architecture – for that I do not need to buy this book.

[Steve · Rating 1 out of 5]

Spoiler: This book is a marketing brochure for the author's $20k course. It's intentionally too vague to be of use, with the premise that the course will fill in the missing parts.

Another book attempting to legitimize "Big Design Up Front" by throwing together some math, design patterns, diagrams, and suggested names. The target audience seems to be non-technical managers and architects who "don't get their hands dirty". The author uses many straw man arguments to explain why this is the One True Way, yet ignores the very real research indicating that 87% of large software projects fail. He provides no legitimate reasons why this method produces designs that won't fall into failure. He attacks Domain Driven Design, which is another Big Design Up Front book that fails to produce results. Frankly, both books are not worth the time, both are entirely subjective, and produce unrepeatable results. The book could have said, "think of green when designing and it'll all turn out perfectly" and it would be as effective.

However, if you MUST do Big Design Up Front, I would consider the middle sections around estimations and slippage worth a read. I might not apply them directly, but the author has put some good effort thinking through all the little ways projects can deviate from their original estimations. I would read the middle again if faced with such a requirement. However, I strongly think that Big Design Up Front should be extremely rare, so if you're going to attempt such a risky endeavor, the parts about estimations should be one out of a dozen other books you should read

This book is dangerous, and causes immense time wasting as teams bicker and fight over No True Scotsman, or in this case, "No True Righting Software Design" meanwhile turning off their brains to actual critical thinking. "Design Pattern" books like this are very risky and should not be written or consumed.

Edit: having read this book a second time, I'm convinced this is entirely a marketing publication to sell the reader on the $20k training courses sold by the author. It's just vague enough to leave the reader more confused than before, with enough zen-like phrases like "most systems only have 3-5 'managers' and should have fewer 'engines'." It requires the reader to learn a whole new vocabulary (replacing perfectly good words with new ones) which just adds to the confusion. All this confusion is by design, because now the reader wants to know more of these mysteries, and has to drop tens of thousands of dollars to learn more. This is an engineering cult designed to fleece people of their money.

[Scott · Rating 1 out of 5]

Big design up front

If you like Big Design Up Front, this book is for you. Otherwise, skip it. Also, the author is one of the most arrogant people I’ve ever read.

[Andrei Olar · Rating 4 out of 5]

This is a book that, refreshingly, goes back to the tried and tested methods of designing software projects successfully. It contains great information and solid techniques used by software architects to perform their job safely and salubriously. It also contains an invaluable piece of advice about integrity.

No book is perfect, though. Reading through some sections can be a bit tougher than need be. In other sections, however, the book could have been more succinct. For example, there are paragraphs devoted to flashbacks instead of merely referencing previous chapters.

To name one thing that sets this book apart for me: the emphasis the author put on project design (as opposed to most software architecture books which emphasise system design).

All in all, I highly recommend reading this book to anyone who is serious about pursuing software architecture and design.

[John · Rating 4 out of 5]

This book has an offbeat sense of humor and seems to take its terminology from much earlier in computers, say the 1980s and 1990s, but that doesn't prevent it from having interesting ideas that apply today.

The prime directive of the book is "Never design to the requirements" (which is unfortunately stated as "Never design against the requirements", implying its near opposite). Instead, assume that requirements are partial and under-specified, and design architectures that can contain use cases matching the requirements, use cases resembling the requirements, reasonable extrapolations, etc.

Using this approach, you can designate coarse blocks that capture what's needed in terms of resources, resource access, engines (core blocks of business logic), managers (which coordinate engines and resource access, and sending messages to other managers), utilities, and clients. Designating these correctly will yield systems and subsystems which will change independently with volatility in requirements across changing needs over users and time.

The manager/engine distinction is missing from other recent books about software architecture, particularly those on domain-driven design, which seem to be all about managers but very little about engines and the core design of the domains.

Despite the apparent strangeness of attempting to architect the system and project plant, including estimates the whole project, upfront, there is still a usefully agile set of ideas hidden here. Effectively, you can reduce the scheduled time through also investing more in interfaces that allow parallel development (compression) and reduce the risk of that schedule slipping by adding slack time back to the project (decompression). The overall effect it to enable a more agile parallel development between teams by asking what communication allows concurrent learning.

Overall, this book presented a really different point of view than many other software engineering books, one that I usually disagreed with on trivial points but agreed with on the fundamental value of creating architectures that allow continued development from ongoing learning while usefully shaping it.

[Wayne Tanner · Rating 5 out of 5]

This book is excellent. Easily the best architecture book I’ve read with many good insights into designing projects in addition to the software itself.

[Keith · Rating 2 out of 5]

A frustrating read. The ideas are solid however the rationale is missing. Examples of why something doesn't work is one thing but it never really explains why "The Method" works better. It also does not factor in corporate politics. Architects can present some plans but without being able to explain why to non-technical people, the approach falls flat.

It also feels like a pitch because "The Method" that is referenced is never clearly defined. Editing could have made this a better book by first presenting typical problems and why they fail. Then the next part should explain the happy path using "The Method" with notes about areas that you can compromise on without losing the project's integrity.

[Artem · Rating 5 out of 5]

Excellent book about architecture including system and project design.
The book is practical and gives actionable advices and recommendations. Author gives reasonable critique of functional and domain decomposition and recommends volatility based one.
I learned a lot. I recommend this book as a desk book to every software engineer and architect.

[Ninja · Rating 3 out of 5]

Interesting perspectives on not just developing the architecture of the project but also on developing the project to deliver the architecture. Not sure I'm convinced of the practicalities of it, but that aside he does a good job of framing the issues of, and surrounding, software architecture.

[Chris Witt · Rating 2 out of 5]

Some useful stuff in here, but ultimately bogged down by the author's bloated sense of self-worth and straw man arguments.

[Aschwin Wesselius · Rating 5 out of 5]

This book took 20+ years in the making. Maybe even 30 years. This book is authored by a technical guy who has an outstanding track record in the field. But he also managed to put his knowledge and insights into teaching material. Like this book. Not only a few tips for improvement, but a whole approach to avoid pitfalls in the design of your software system. Any software system. From start to finish.

No, he doesn't take your hand and go through step 1, step 2, step 15 etc. Each system is different. But he explains his approach and also why this approach is so successful. He also explains why it is possible to learn this approach to apply it yourself. Yes, it is thorough. It is tough. But that's why it is called a software development crisis. Software design and development is hard. At least he gives you the opportunity to learn from your mistakes and how to do better next time.

How many systems have you build on time, on budget and with zero defects? 50? 10? 5...? Ok, you probably, just like me, have never build such a system. Even if you have build one it's a hell of a feat to pull.

Well, Juval Lowy has developed a method from his experience in the field to do this. Even better, he gives you a glimpse on how to do this in this introduction book. I get it, many people think he's arrogant and cocky. But he is far from it. It's a facade he's using effectively.

He and his company and associates have build hundreds of systems on time, on budget and with zero defects. And he is teaching thousands of architects doing the same thing. Not many people can say the same thing. He's actively involved in guiding people improving their systems or starting new ones from scratch.

Juval knows why software development is hard. He also knows why it fails so often and he can explain why the software development crisis exists and why it hasn't been solved since its inception. But he's also one of the few who actually is sincere in trying to solve this crisis.

He organizes master classes and clinics. Yes, for money. Heaps of money. No, just kidding. The fees are normal fees that cover the costs of preparing, executing these courses and to do support afterwards.

Juval is the mister Miyagi of software development. A teacher, a master, a sensei. Both on the technical side as the practical ans soft skill side. He's been there, he's seen it all and he's about to teach his lessons learned.

This book is like a paper by Ignaz Semmelweis: software architects and developers refusing to wash their hands because it's a ridiculous theory and it will never work. It will prove itself wrong any time now. Truth is, washing hands saved lives after Ignaz passed away and doctors all over the world adapted his approach. Let's think about it from a sincere point of view: how many lives can be saved if software systems weren't failing because there wasn't a proper procedure in place to prevent fault and errors from happening? Airplanes crashing. Medical equipment interpreting information wrongly. Energy plants not secure enough or easily got cracked after the latest patch. Etc.

PS: If you have more authority than Juval Lowy on this subject I'm happy to hear your arguments on why this method is wrong. Please include your track record of successfully deployed systems on time, on budget and with zero defects.

[Andrei Vajna · Rating 4 out of 5]

Not having yet the chance to put the techniques into practice, I can't say if they are as good as the author boasts them to be. Some areas seem very briefly presented, but it is a very complex subject, and each area deserves its own in-depth book. That said, I think the book presents a very compelling overview of how to approach a software project in a systematic, engineering manner. From what I've seen of the software industry in my over 10-year career, the process (if you can even call it that) seems so chaotic. It feels like even trying to apply the method presented in the book would improve the status quo significantly.

I mean even trying to do some planning and calculations based on the techniques from the book would give you useful information on the project you are dealing with, which is infinitely better than zero information you usually have or try to gain. You learn how a project is expected to behave and what you can do about it, rather than trying to do random things based on instinct and no quantifiable measures whatsoever. Of course, there is a long way to go in order to ensure your project succeeds, but no book can help you with that, you just have to practice what you've learned.

[Steven Jøris · Rating 2 out of 5]

This book definitely has interesting things to say, and draws on clear seasoned experience. However, unfortunately it decides to ignore any other relevant material written on the subject over the past 20 years or so. I'm thinking of concepts like:
- Domain-Driven Design
- Agile
- Continuous delivery
- Microservice architecture

That also means it lacks critical reflection of the concepts presented, and a consideration whether the presented techniques work equally well in different types of projects.

Also, I found the overreliance on mathematical notation/graphs/reasoning to give extra power to the author's arguments largely misplaced. It reminds me of bad practice in software engineering literature which Laurent Bossavit has written about in "The Leprechauns of Software Engineering".

That said, as a software architect much farther removed from project management than Juval argues architects should be, I did learn a thing or two on how I can help improve collaboration with project managers; not that I intend to incorporate project management into my daily work to the degree Juval suggests.

[Iwan Cwetanow · Rating 1 out of 5]

Disclosure: Couldn't even finish the book

The first big red flag to me comes up in the beginning where the author states that he has solved all the problems in the field - build a project that meets all the requirements, has perfect structure and is on time and budget. This holy grail is achieved by using THE METHOD of course.

So how to build software - you get the perfect design from the start and then build it (waterfall maybe?).

Did not quite understand the examples that compare building software with building a house.
The author has some beef with functional decomposition and instead suggests volatility based decomposition but I didn't quite understand what he means by that with the house examples tho and that's where he lost me (yeah about 10% of the book and didn't continue, maybe lost out on a goldmine 🤷‍♂️)

[Dan Kuida · Rating 5 out of 5]

This is not easy reading. It feels like highlighting every second sentence in the book. Changed the way I approach a project ground up. Knowing some of the work from previous books by Juval - I already gained a win. The volatility-based decomposition saved a hurdle in an architecture design the moment I write these lines. You all know Microsoft ceasing .net framework. Imagine what is happening to architecture that did not encapsulate that.
It is not an on the shelve book - it is an on the table playbook - in the whole lifecycle of the project. I literally put in clients' contracts to buy the book for every office I am visiting.

[Carlos Villarroel · Rating 5 out of 5]

What a boom from Juval Löwy, if you like software architecture you definitely need to read this book. This book isn't about code, is about how to build a project from zero, planning the architecture, the services. You will learn how to decompose a system into smaller building blocks or services. I highly recommend to read this book if you are a software architect or a project manager for IT projects, learn how to flow an effective project design from the system design, how to calculate the project duration, cost, and risk, how many people you need to have success, this book is a methodology that you need to read, learn and apply constantly.

[Alan · Rating 5 out of 5]

Phenomenal book. While the language around architecture did not grab me if you do not have an existing framework to talk about system design it is better than nothing. The project design content is exquisite. I know there are others that may not find it palatable or realistic but there is great value in applying these ideas. Now you might not use it for a product you are searching for product-market fit. However, if you have a platform and a mandated activity like security this makes perfect sense. The key quote from Juval is that project success is meeting your commitments. If you work on software and reject providing estimates and deadlines you will not rise very far.

[Ethan Benson · Rating 3 out of 5]

Pretty good, but the quasi-religious undertones are off putting. Some good ideas - Volatility Based Decomposition is a life changing concept (at least for me) - but it reads too much with the tone of “I’m right, because I’m right, and if you don’t agree you weren’t paying close enough attention, re-read the chapter”. Most of his examples weren’t super practical. It seems like it was a cutting edge work in the mid 90s but doesn’t really seem useful in our debt-fueled, MVP, VC-backed industry. Maybe if you’re making internal facing software and don’t have a deadline. But Volatility Based Decomposition is a fantastic concept and worth thinking about.

[Wayne Cheetham · Rating 5 out of 5]

Contains theory from both the Architect and Project Design Masterclass courses from Juval. A great quick read covering how to deliver on budget, schedule and risk, linking all of these to solid architecture and continuous planning.
Perhaps missing but you can find in youtube are his views on agile and how delivery to the first Client service delivers the first feature/s.

I think all Architect's and Software Team Leaders/PMs should read this book and challenge their current thinking and assumptions.

[gargamelscat · Rating 4 out of 5]

A high quality book of literally two halves: first half is practical software architecture and second half is project design.

The latter is interesting but a bit of a slog if project management is not your central interest. I found the first half particularly rewarding.

Stand out take - a functional decomposition approach to software design at the project level will almost always result in failure or at least the kind of tightly-coupled maintenance quagmire so many code bases end up in.

Opinionated and thought-provoking this is well worth reading.

[James Abreu · Rating 3 out of 5]

Some interesting ideas about project planning, pitching designs to stakeholders, and techniques to control risk, complexity, and other concepts. It felt really dense for what could have been a much smaller book. I don't find myself willing to sit down and do the math presented in the book for any kind of project I would work on, but I could see some merit for much, MUCH larger projects.

[Alex Garzão · Rating 3 out of 5]

It is a good book, very well structured. My expectation was to read more about systems design, but the main focus of the book is project design. Despite this, "the method" explained in the book is a really cool approach to deal with projects.

[Eric · Rating 5 out of 5]

The author is not shy about his track record in software architecture (he proclaims perfection). So far the book has gone into his methodology for analysis and design of software.

[CarlMarx · Rating 5 out of 5]

thanks! a real must read

[Donald Mason · Rating 5 out of 5]

Can't post a review for some reason.

[İbrahim · Rating 3 out of 5]

Architecture part good but project management part boring a lot couldn't finish that part

[Dan Kuida · Rating 5 out of 5]

This is not an easy reading. It feels like highlighting every second sentence in the book. Changed the way I approach a project ground up. Knowing some of the work from previous books by Juval - I already gained a win. The volatility based decomposition saved a hurdle in an architecture design the moment I write this lines. You all know Microsoft ceasing .net framework. Imagine what is happening to architecture that did not encapsulate that.
It is not an on the shelve book - it is an on the table playbook - in whole lifecycle of the project. I literally put in clients contract to buy the book for every office I am visiting.