In finance there is the concept of "Risk Adjusted Returns" -- in the case of a re-write, time efficiency is not a sufficient conceptual framework for talking ab

In finance there is the concept of "Risk Adjusted Returns" -- in the case of a re-write, time efficiency is not a sufficient conceptual framework for talking about it, because it's risk laden. For example, I would much rather take 2x as long to accomplish the goal, if its 10x less likely to result in catastrophic failure. A failure to recognize the risk vs time tradeoff I think can lead to a failure of being motivated enough to "work the problem" -- often there is a continuum of changes that exists -- and it might not be "smooth" and could be in fact quite painful -- but it will be way, way less risky. It's often so less risky to transition software incrementally vs bet the farm on a rewrite, I feel like in most contexts a rewrite should just be ruled out completely without further discussion: better to just muddle through and try to figure out a way to survive without it, since you may come up with a better solution that is less risk laden just by waiting (due to new ideas, new technology, new market opportunities, etc) and not stalling your current product development and risking that you'd effectively destroy everything of value you've created so far due to total stagnation.