Lean Software Development: Before and After the Last Responsible Moment

The Last Responsible Moment (LRM) is a lean development principle defined as:

“A strategy of not making a premature decision but instead delaying commitment and keeping important and irreversible decisions open until the cost of not making a decision becomes greater than the cost of making a decision.”

Let tbe the specific point in time for a concrete design decision Di. The LRM principle tells us that tshould be deferred as much as possible. One of the reasons is to avoid making decisions based on assumptions, so that we should decide when we have optimal information about the requirements and there is a reduced risk that our decisions will need to be changed.

LRM1During the incremental software development process we will implement a set of concrete design decisions D1 … Dn, in which D1 … Di-1 are the decisions implemented before Di, and Di+1 … Dare the decisions made after Di. This order of decisions is not arbitrary and will follow some design rationale.

LRM2But of course these design decisions are not independent of each other. Thus, among the decisions D1 … Di-1 there will be some of them that depend on Di. For example, if each design decision Dj is encapsulated in a class Cj, we must know at least the interfaces of the other classes being used by Cj.

Before the Last Responsible Moment

This means that for each design decision Di there must be a point in time, before ti, in which we define an abstraction for Di. This abstraction allows the implementation of all design decisions that depend on Di but must be made before it. If Di is represented as a class, the abstraction would be its interface, and it should be defined at a time tAi < ti.

LRM3This definition of abstractions before implementations is exactly the result of Test-Driven Development (TDD). When we write unit tests for a class we are defining its interface, both at the syntactic and the semantic levels. By the time all unit tests are written for class Ci we have reached tAi, but we are still before ti, the last responsible moment in which we will decide how to implement Ci.

After the Last Responsible Moment

No matter how long we were able to defer a concrete design decision Di, there will probably be a moment in which it will need to be changed. The last responsible moment is the first time we provide an implementation for an abstraction, but certainly this does not mean that there is any guarantee that this implementation will never be modified.

LRM4For every design decision Di there may be a time tCi > ti in which its implementation is changed. We do not want this change to affect the modules that depend on Di, and this can only be done by preserving the interface. Therefore, the importance of abstractions is twofold: they allow concrete design decisions to be deferred until the LRM, and they also allow these design decisions to be changed after the LRM.

Conclusions

In order to adopt the Last Responsible Moment principle it is essential to focus on the definition of abstractions representing the diverse design decisions. These abstractions serve as the placeholders that will allow the concrete implementation details to be deferred as much as possible. Moreover, good abstractions are essential to support maintainability and allow these design decisions to be easily changed.

About Hayim Makabee

Veteran software developer, enthusiastic programmer, author of a book on Object-Oriented Programming, co-founder and CEO at KashKlik, an innovative Influencer Marketing platform.
This entry was posted in Lean Development, TDD and tagged , . Bookmark the permalink.

3 Responses to Lean Software Development: Before and After the Last Responsible Moment

  1. Gene Hughson says:

    Two observations that were made in the post are, in my opinion, strong support for ADUF:

    “During the incremental software development process we will implement a set of concrete design decisions D1 … Dn, in which D1 … Di-1 are the decisions implemented before Di, and Di+1 … Dn are the decisions made after Di. This order of decisions is not arbitrary and will follow some design rationale.”

    and

    “But of course these design decisions are not independent of each other. Thus, among the decisions D1 … Di-1 there will be some of them that depend on Di.”

    Without sufficient up front analysis and design, it will be difficult to identify the dependencies that determine the order of decisions. Failure to do so risks missing an LRM due to lacking sufficient information to determine it correctly. This will most likely lead to heavy refactoring of the design, technical debt or some combination of the two.

  2. Pingback: Manifesto for Adaptable Software Development | Effective Software Design

  3. Pingback: Indefinite Optimism: the Problem with the Agile and Lean Mindsets | Effective Software Design

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s