There are a lot of design patterns, techniques, and ideas around us—both online and offline. An architect can always look towards them for inspiration. But it is very important to ignore the noise. In this series of articles, we will follow the book Righting Software by Juval Löwy, which refers to the entire concept of project and system design as "The Method". We will also refer to this idea as The Method throughout the series.
By system design, we mean the design of the architecture, not the detailed design—which deals with how classes, interfaces, and contracts should be built within a component. Detailed design can be discussed in another series.
There is a common misconception that a good architect needs decades of experience building systems to know what the right design decisions are. In this article series, we’re going to challenge that notion. We’ll explore how system design is not just tech—it’s an art, just like in other engineering disciplines. The book Righting Software draws strong parallels between system design and civil engineering. I myself am a mechanical engineer by education. Working as a software engineer, I love identifying the similarities in design thinking between successful engineers in both domains. I’ll also try to share some successful design ideas from mechanical engineering that align with the principles of The Method described in the book.
Crux Idea of The Method
It’s undeniable that analytical skills, problem-solving, and a good attitude are essential for becoming a great architect. But beyond these, the art of designing systems will certainly grow through this series. The crux of the book lies in dividing a large system into modules and components, and defining how these components interact.
In this series, we will focus on System Design. But as Juval emphasizes—Project Design is far more important than System Design.
Design Validation
A good design:
- Must address customer requirements
- Must align with team capabilities
Once coding and development begin, there’s no turning back. A flawed design can cause immense pain a few years down the line as the system grows—possibly requiring a complete rewrite. That’s why it is critical for the architect to take full responsibility for delivering a solid system architecture. A design should never be a risk. No project should fail because the system has become too complex to build upon.
Just like a house architect designs a plan in a few days and the house is built over years using that plan, a software architect should also aim to design in days—so the development can continue for years without regret.
Software Design Decision Tree
Any complex system is designed by breaking it down into hierarchical, tree-like decisions. Each leaf in this tree represents a complete design decision tied to a specific requirement.
A Bad Design Tree
When an architect is unaware of the right decision process and doesn’t start from the root, they end up validating each component against every other component.
If there are n components, the architect ends up with n × n iterations—leading to design paralysis.
A Good Design Tree using The Method
A good design decision tree starts from the root and proceeds to the leaves, where each leaf represents a distinct, isolated decision. The more constraints the system has, the easier it is to create a good design. With a blank canvas and no constraints, there are infinite ways to go wrong.
The Method imposes increasing constraints on both the system and the project until the design converges naturally and resolves quickly.
One of the strongest advantages of The Method is that the resulting design communicates clearly. Once you’ve built the design, you can easily share and explain it to developers, product managers, and other stakeholders. A reviewer can quickly navigate through the design’s structure and rationale. That’s the level of clarity and transparency The Method aims for—thanks to its well-defined service semantics and architectural structure.
No amount of passionate argument can match what a simple set of charts and numbers can communicate.
Conclusion
System design doesn’t have to be a mysterious or overwhelming process reserved for the most experienced architects. With the right mindset, clear principles, and structured thinking, anyone can learn to design systems that are scalable, maintainable, and aligned with business needs.
In the upcoming articles, we’ll dive deep into each step of the method, breaking it down into practical, understandable parts. I’ll publish one article every Sunday to walk you through the process—step by step.
Stay tuned!
Top comments (1)
Waiting for the next Sunday! 🙌