As I briefly mentioned yesterday, there’s a concept in Lean software development called deferred commitment, or more colloquially, decide as late as possible:

As software development is always associated with some uncertainty, better results should be achieved with a set-based or options-based approach, delaying decisions as much as possible until they can be made based on facts and not on uncertain assumptions and predictions.

We can apply the same principle to many areas of life. When driving down a 5-lane freeway during rush hour, which lane should you be in (ignoring, for the purpose of our thought experiment, any laws that may require you to drive as far to the right as possible)? All else equal, you probably want to be in center lane. This gives you the maximum flexibility. You can choose to change lanes left to pass, or change lanes right to prepare to exit (assuming a RHT country).

As you near your destination, you’ll want to commit to the right lane, to prepare to exit, limiting your option to pass on the left. Committing too early to the right line would likely delay your arrival, as you would have little or no option to pass slower vehicles.

This principle of Lean software development is often criticized for being too limiting. And rightly so, I think, to a degree. It’s not always appropriate to wait to make a decision. Waiting until the last possible moment to change to the right lane can be disasterous, too.

While deferring commitment serves as a good general rule of thumb, it’s not a commandment. I like to change the rule from “Decide as late as possible” to “Don’t decide until you have a good reason.”