"The last responsible moment (LRM) is the strategy of delaying a decision until the moment when the cost of not making the decision is greater than the cost of making it."
Still trying to unlearn that one. Turns out, most decisions are cheap to revert or backtrack on, while delaying them until Last Responsible Moment often ends in shooting past that moment.
Depends who you are, mostly the ones making the decisions aren't usually listening to their developers (maybe by choice maybe because they are at the whim of a customer), so their cost functions are calibrated towards course changing being more expensive than less.
By the time your devs are saying "this sucks" you've long overshot.
That's a good point. The (estimate of the) cost function is key, it determines whether delaying decision is better or worse than making it eagerly and reverting if it turns out to be wrong. You give a good case for when delaying is a better choice.
In my case however, I ended up applying the "LRM" strategy to my own work, where I'm both the decision maker and the sole implementer. This is where I see my mistake. In my defense, the software development books that argued for delaying decisions did not warn that this applies to larger decisions in projects developed by teams, and may not apply to small-scale design decisions made by an individual contributor or a small team in the scope of a small piece of work. It took me way too long to realize that, for most of my day-to-day choices, the cost function is pretty much flat.
We're moving out of business context and to more general one, as I have more experience there - I learned the idea of postponing decisions from software design, and mistakenly started to apply it to my life in general :).
It's absolutely true that postponing a decision lets you take advantage of more data and experience. But making a decision now also generates new data - and often does it better and faster: you're directly observing how your choice plays out in the real world. For cheaply reversible decisions it means that, when things go bad, you can go back and make a new decision, this time informed by knowledge of what went wrong with your previous choice. If you squint, it almost looks like time travel :).
Not every decision is going to be like that, but e.g. in software design, I would often delay deciding between several possible approaches to seek out more information (and/or wait for it to come from customer side), only to later realize that in that time, I could've prototyped most or all of the options, or I could've picked one and made progress and undo it fast when more information came - and that either of those two approaches would've let me to gain the missing data faster, while also keeping forward momentum.
There's a reason many programmers (myself included) need to repeatedly hear the mantra that goes: "make it work, then make it right, then make it fast". In my case, postponing decisions is often a kind of analysis paralysis, and I'm slowly learning that in many cases, it's better to just pick any option, "make it work" in the dumbest, most straightforward way possible, and then reevaluate.
But as I said, I am learning this slowly. My mind knows better, but my heart still wants to delay by default :).
Agree with all of that, and want to add a shoutout to the Cult of Done [0].
Very few things need to be perfect, or right first try. Waiting until the last possible moment is a version of perfectionism that is often counter-productive. Trying something out before it's needed gives room to experiment and discover new approaches.