Technical Decisions Series - Decision Reversibility and Lean Software Architecture -Part1

Decide as late as possible

In the book Leading Lean Software Development: Mary poppendieck, a pioneer in applying Lean thinking at Software development, argues about the need to decide at the Last Responsible Moment, this principle has many names and  it is one of the core concepts of lean.  The key insight in this principle, is that, there is a cost of change associated with modifying parts of a system, which increases rapidly as time passes and the system becomes more complex.

In Construction and Hardware this observation is almost obvious. When a building is still in planing phase any change in the blueprints, has almost no cost. But after construction, modifying the architecture, even for minor changes becomes very costly .

Many decisions are obsolete - but we just don't know it yet.

Everything seem important and urgent in the beginning of a project. But i have been in many situations, where if you postpone a decision long enough eventually, becomes irrelevant and obsolete. Clients insisted on the importance of a feature but when the application gradually crystallizing , the feature is not so compelling anymore or even unneeded. Feature prioritization is a mandatory practice, and agile is on spot.

Last Responsible Moment and Architecture

Thus Deferring irreversible decisions means you keep your options open for as long as possible. Robert C. Martin author of Clean Code, gave a great presentation (worth watching )on Clean Architecture and Design, in which he discuss his mindset about software architecture.

He made clear, that there is a high degree of correlation between deferring decisions and good architecture. This is one of the main reasons that, Domain Driven Design (DDD) gained so much popularity in complex domains the last period. Is integral in DDD to defer decisions about non-critical component like, which Database will be used or which web framework will be used for the UI. In almost any initial designing sessions for an application that i have been in, the team seem to focus at the technology. I have found out that just by asking the question  - " What should be the structure of the application, if we do not know yet what Database/UI framework/Technology we will be using ", forces the team to come up with better architectures by shifting the attention to the core of the domain. This is a deferring commitment question.

Below we see the onion architecture (hexagonal A.k.a Ports and Adapters)- a predecessor of DDD - that defers infrastructure and UI to the periphery of the system (for example : Avoid answering the question about what Database we will be using, automatically force us to consider Repository Pattern and Unit of Work, in order to avoid a dependency on a specific technology  - which Eric Evans included in his initial formulation of DDD)

 Is Design Dead ?

Martin Fowler in a great article about software design named Is Design Dead ? following the  same theme, talking about the idea of Evolutionary Design . The consequence for evolutionary design is that designers need to think about how they can avoid irreversibility in their decisions. Rather than trying to get the right decision now, look for a way to put off the decision until later (when you'll have more information) .

Conclusion

Thus Deferring Commitment is a very good tool for improving the quality of technical decisions (and any other type of decision as a matter of fact as we will expand in the continuing article) and should be in the arsenal of anyone who is part of a team that makes application Design decisions. One way to incorporate right away this tool to your practice as Kaizen would suggest, is just asking the question "should i decide about that now, or it can be decided latter ?". this might be the only good type of Procrastination .

Remember the programming Koan

No code is better than no code