It can be helpful to write down the context of why you made your decision, so that if/when you revisit it later itβs more clear. ADRs are one way to do this: https://adr.github.io/madr/
Short of something structured, any format that captures key assumptions and intentions is good. The problem we are solving is X. The "pre-mortem" is the idea is that if we fail, it would be because of Y. Then in your design or decision, you address Y as a contingency. The collateral idea for code would be "good until" - this is good until (we expect) some threshold.
I've run into at least a few people who can't understand why my answer changes when the context changes. I said we were going to do A because of C, D and E. Why are you acting like it's a gotcha when we find out E doesn't apply anymore and now I agree B is a better option?
Did you think we were joking when we said, "It depends"?
Great advice. I also use learning milestones to manage our novelty budget and record our findings/decisions/context/etc. I don't know if this is formalized or written down anywhere.
The idea is that when your team wants to try something and learn from it you record down your thoughts and ideas into a document. You then have a triggering condition in that document for when to review it later. When you do the review you record what you learned and what decisions you make as a result.
Over time your teams build up little libraries of these learnings and it can help build organizational continuity. People come and go, leaving teams or the company, joining other teams, etc. It's a good practice to avoid having to re-transmit what your organization has learned through re-telling folk-lore.
