Reading Righting Software

In July 2023, I attended and presented at NE Code in Lincoln, NE where there were several presentations about Software Architecture. Billy Hollis, in his Keynote - Lies Developers Tell Themselves , mentioned Righting Software by Juval Lowy in a passing slide as a “good resource to up your architect skills.” I was hooked and brought back the suggestion for the next book club.

We read it as a group and shared our thoughts in an Omnitech blog post .

Since I wrote most of it, I’m cross posting it here with permission.

Overall Review

Righting Software: A Method for Systems and Design is extremely dense and full of intense content. We found it was best consumed as a group and then discussed together. We can tell that Juval Lowy thinks deeply and is very experienced.

Designing software architecture and how the project will be run are both especially important topics for creating software. Studies have shown that up to 70% of projects fail in the industry. This has led to a lot of waste, stress, and hardship. Over the years, we have learned and improved our process of building trust by creating software that provides value and supports our clients’ businesses.

This book has opened our eyes to the possibility of applying stricter engineering approaches to the planning side of software. While no one can argue with that, Lowy’s approach isn’t for everyone.

Starting the book by stating, “I never failed” and calling his process “The Method” made us a little wary of his mindset. This discouraged some of us from continuing the book club, but those who stuck with it would recommend starting the book by reading Chapter 14. This gives a more rounded view of his thinking, which is easier to digest and doesn’t seem as high-minded. It also provides a great context for the rest of the book.

Software Architecture

Juval presents “The Method” to apply first principles of engineering to software architecture. He proposes that Clients, Managers, Resources, and Resource Access “decompose a system into smaller pieces based on volatility.” He teaches functional decomposition (which is the first approach of many and has shown to be harmful to systems) vs Volatility Decomposition (considering the impact of change and isolating those pieces with boundaries).

The Prime Directive is “Never design against the requirements.”

Identifying functional vs volatility decomposition is something we will need to grow in. He did tell us that “The Method” takes time and effort before starting the project but will yield a good return on investment.

“The Method” is at such a high level that we thought almost any project could fit. The challenge is learning and gaining the experience to apply these principles to the specific details of each project. We realized we can’t apply all the concepts but can find a good balance of putting the extra effort up front vs. having the team discover what is required and adapt as needed. The many diagrams and discussions of the options of architectures, questions to ask, and ways to visualize and document have helped us grow in our understanding of building adaptable systems.

Comparisons to Clean Architecture

Clean Architecture  by Bob Martin has been a bedrock of our understanding of good software over the years. We see a lot of similarities to “The Method.”

Project Design

Lowy recommends giving stakeholders the best three options based on risk: time, cost, and resource availability constraints, and then providing a 4th option that is not as good as the first three and solely serves to contrast the three good options. Discussing the pros and cons of the three options - along with a 4th option will enable objective, non-confrontational discussion of the risk and feasibility of a project before starting. This should lead to better decision-making.

He spends a lot of time teaching how to identify the “critical path” of tasks to determine timeline and cost and to understand dependencies.

In Chapter 11, he suggests that most projects can be compressed by starting with infrastructure. You can consider client implementations with simulators to increase parallel work to reduce the timeline but increase complexity and risk.

We appreciated his in-depth walkthrough of a sample project to illustrate all the concepts he introduced.

Lowy said his best advice was to “treat the company’s money as your own.” If you invest money in a software product, wouldn’t you put in the time and effort to create a plan first to help decide the feasibility and cost schedule to pay for it?

Comparisons to Sooner Safer Happier, Agile and DevOps

Agile, the DevOps movement, and Sooner Safer Happier have taught us that we need agility to keep up with the rapid changes that occur. We build in an emergent environment where the current work has never been done with this technology, in this business environment, with the people we have. The mantra is that if we can adapt well and learn in small iterations, we can improve our outcomes. There have been massive improvements in the industry with these approaches, but still, many software projects “fail.” The industry would benefit from putting more effort ahead of time to apply “The Method” and project design. We believe there is a balance and that they are not in conflict.

Righting Software provides some concepts that jive with Sooner Safer Happier, like the importance of understanding the business context of your work and how that context should be reflected in your software. The author argues that when your software architecture groups and encapsulates the core non-volatile features of the business properly, any requirement changes will be supported within the architecture.

Please see Omnitech’s Sooner Safer Happier Book Club post for more thoughts.

Summary

What we learned will impact how we approach software architecture and project design individually and as a company. We will continue to learn, apply, and share with others.

It was a challenge to summarize the ideas. We suggest you listen to Juval Lowy in his own words and to read this book with others if you are willing to put in the time and work to understand this topic more deeply.