I think the important lesson is to use clear eyes to evaluate what the rewrite buys you. I was on a team that rewrote a native code app in C#. We also had access to early cloud tech in the Azure stack, what is called queue now and then was called service bus.
These two technologies combined greatly simplified this specific product making it far easier to maintain. Performance on these services was not important so native code was carrying a lot of penalties without the benefits.
Having a well documented messenger like service bus with great SLAs removed several tools we had needed in the old implementation.
We were able to leverage the tests form the original product to define success and tmthus were able to solve a lot of the edge cases in the new code w before we even shipped.
However, the old code was perfectly fine code. If new technologies had not provided significant simplification of the service architecture, a rewrite would've been foolish. And without the very good previously existing tests, we would've run into a lot of issues as we released.
These two technologies combined greatly simplified this specific product making it far easier to maintain. Performance on these services was not important so native code was carrying a lot of penalties without the benefits.
Having a well documented messenger like service bus with great SLAs removed several tools we had needed in the old implementation.
We were able to leverage the tests form the original product to define success and tmthus were able to solve a lot of the edge cases in the new code w before we even shipped.
However, the old code was perfectly fine code. If new technologies had not provided significant simplification of the service architecture, a rewrite would've been foolish. And without the very good previously existing tests, we would've run into a lot of issues as we released.