4 ms·

> I'm sure everyone can come up with a million other reasons. Indeed. One reason for rewrite is that there isn't a smooth continuum of changes from vCurrent t

> I'm sure everyone can come up with a million other reasons. Indeed. One reason for rewrite is that there isn't a smooth continuum of changes from vCurrent to vFuture. If the discontinuity will have to be bridged anyway, and if other intermediate changes aren't going to bring sufficient improvement, jumping into it might be the most efficient way.

gfodor 7y ago
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.
- convivialdingo 7y ago
  On my 5th startup - I cannot agree more. You only have so much cashflow - your first priority is to maintain and deliver for your customers. They pay the bills usually. Architecture and engineering are important, and they need support and time to rework problems. But incremental improvement is almost always the best choice. If you have the cash then you should consider not only what’s best for product maintenance, but also how you could use that cash to grow your business.

gfodor 7y ago

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.

convivialdingo 7y ago
On my 5th startup - I cannot agree more. You only have so much cashflow - your first priority is to maintain and deliver for your customers. They pay the bills usually. Architecture and engineering are important, and they need support and time to rework problems. But incremental improvement is almost always the best choice. If you have the cash then you should consider not only what’s best for product maintenance, but also how you could use that cash to grow your business.