Have you ever found yourself at a crossroads, torn between options... with pressure mounting from other leaders... when, really, that choice didn't actually need to be made?
What if I told you that delaying decisions until the "Last Responsible Moment" (LRM) can actually be a strategic advantage?
Let's imagine this scenario: you're building a castle. The foundation is laid, and you're about to choose the material for the walls. Should you decide right away or wait? The latter might allow you to make a more informed choice as you could consider the most recent ecological, economical, or even aesthetic developments. The same principle applies in software architecture.
The Last Responsible Moment is a strategy in lean development that emphasizes the importance of delaying certain decisions in software development until the cost of not making a decision becomes greater than the cost of making a decision.
But, how can we discern the last responsible moment? How do we balance between the risks of acting too soon and the perils of waiting too long? The answers lie in understanding the essence of LRM and its strategic implications.
Understanding the Last Responsible Moment
LRM is the idea of delaying a decision until the point where not making a decision would cost more than making it. It recognizes that some decisions have long-term effects and can be difficult to reverse.
Bezos wrote the following in a shareholder letter:
Some decisions are consequential and irreversible or nearly irreversible – one-way doors – and these decisions must be made methodically, carefully, slowly, with great deliberation and consultation. If you walk through and don’t like what you see on the other side, you can’t get back to where you were before. We can call these Type 1 decisions. But most decisions aren’t like that – they are changeable, reversible – they’re two-way doors. If you’ve made a suboptimal Type 2 decision, you don’t have to live with the consequences for that long. You can reopen the door and go back through. Type 2 decisions can and should be made quickly by high judgment individuals or small groups.
As organizations get larger, there seems to be a tendency to use the heavy-weight Type 1 decision-making process on most decisions, including many Type 2 decisions. The end result of this is slowness, unthoughtful risk aversion, failure to experiment sufficiently, and consequently diminished invention. We’ll have to figure out how to fight that tendency.
I assert that using LRM, we can reasonably defer many Type 1 decisions and deliberately wrap them in Type 2 style decision studies. Calling back to our castle example, our benefactor might prefer the concept and aesthetic of solid Italian marble construction but has neither the budget nor the patience to wait for sufficient raw material for the entire castle to be cut and shipped.
Instead, we might collect material samples. We could use the samples to observe how they respond to the sunlight at different times of the day. We might test the material properties for strength and durability to the outside elements. We might construct a gatehouse or fountain so we can continue to gather data about how the materials will actually be used and how they respond to that use.
These, as you may recognize, are small-scale Type 2 choices of varying levels of investment using the real location and exposing the options to live use so we can gather data relevant to our Type 1 decision.
What LRM Means
Gathering High-Fidelity Information: LRM is about collecting as much accurate and relevant information as possible before committing to a decision. It acknowledges that future information can alter the path, making the decision-making process more flexible and adaptive.
Balancing Costs: LRM focuses on weighing the cost of delaying a decision against the cost of making it. It aims to minimize risks and take advantage of evolving circumstances.
Responsive Adaptation: The strategy fosters adaptability. By not committing early, it allows for adjustments and adaptations to the changing environment or new insights.
What LRM Doesn't Mean
It's Not Procrastination: LRM is not an excuse for indecision or procrastination. It's a deliberate strategy that seeks to make the best decision possible given the available information.
It's Not Doing Nothing: LRM doesn't mean standing still. It's about actively seeking out new information, evaluating options, and preparing for the decision.
It's Not Avoiding Responsibility: Rather than shying away from responsibility, LRM embraces it by acknowledging the importance of the decision and taking the necessary steps to make it wisely.
LRM in Software Architecture
Software architecture decisions can be crucial and often irrevocable. Here's how LRM plays a pivotal role:
Flexibility in Design
By embracing LRM, architects can keep options open, allowing for more flexibility in the design process. This flexibility often leads to more innovative solutions and better alignment with evolving business needs.
Risk Mitigation
LRM helps in identifying and mitigating risks by not locking into decisions prematurely. It provides time to analyze different scenarios and outcomes, reducing the likelihood of costly mistakes.
Enhancing Collaboration
LRM fosters collaboration by encouraging continuous communication within the team. As the team gathers information and evaluates options, it enhances the shared understanding of the problem and potential solutions.
Embracing Strategic Delay
The Last Responsible Moment is not about indecision or delay for delay's sake. It's a strategic approach that emphasizes the importance of timing, information gathering, and thoughtful evaluation.
Software architecture decisions can have profound and lasting impacts, and embracing the LRM approach ensures that decisions are made with the highest degree of insight and understanding when it matters most.
It's a strategy that doesn't shy away from decisions but prepares for them, allowing teams and organizations to navigate the complexities of software development with agility, wisdom, and confidence.
Top comments (2)
I hadn’t heard of LRM before but this is an extremely well written and clear article and I really enjoyed reading it. Thanks for sharing.
I like the idea of LRM because it seems like if it is done properly it would require prototyping and the Agile iterative type of development (which I am a fan of).
Hey, if you get a chance, would you mind reading my latest article here on dev.to and commenting? Software Developer, Are You Just a Hammer?
Done and done! Nice work.