Edit: I suppose this is the opposite of the Sunk Cost Fallacy. :S
I do. I previously posted my dev history, which contained this:
When I first came back on board 4 years ago, the plan was to do a big bang rewrite of the system. In the back of my mind I knew it was a bad idea, but there was general agreement that it was the best plan. It was also a siren song to start the architecture with a clean slate. However, since I had been gone the system had become pretty sprawling with a lot of apps integrated through a database. As I developed the new system, it became harder and harder to understand how we could possibly migrate to it from what we had. Eventually, the executives got tired of not getting business value from my expensive salary, and directed me to fix some really painful issues in the legacy app for a while. It was after that point, my manager and I agreed to abandon the rewrite. Instead we started implementing the good things we learned from the rewrite into the existing system. We made a lot of positive changes to ease pain for various users. (And we still have a lot of work to do, but we can at least see a path forward.)
However, I have successfully done rewrites before (on the previous project, in fact). But the only successful rewrites have been progressive rewrites, not big bang. It goes right along with this quote.
A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work.
John Gall
Our legacy system still has numerous known issues. It's like a hallway with lots of immovable obstacles and things sticking out of the wall. You eventually learn how to navigate the hallway and it becomes normal. But it limits what you can carry through it. So I have been approved and have started a progressive rewrite. This time I am doing a parallel system, and propagating data to the legacy system which is necessary to keep it functioning. Then migrating piece at a time to the new system and turning off that piece in the old system. That's the plan anyway.
When to rewrite
It is rarely worth rewriting simply to re-express the same solution on top of a different platform (framework, language). In that situation, all you really see are the upsides to the new platform. But it isn't until you get into it that you begin to see the new challenges. It often ends up with an equal amount of issues, but they are just in different places.
I usually find it worth a rewrite when the current code base / system constraints both restrict new kinds of features and resist being refactored. This ends up increasing the overhead of a new feature to be many times the cost of the feature implementation code itself. But the only way to make an improvement by rewriting is to first figure out a system/organization strategy (design, architecture) which is a better fit for your situation.
Edit: I suppose this is the opposite of the Sunk Cost Fallacy. :S
I do. I previously posted my dev history, which contained this:
However, I have successfully done rewrites before (on the previous project, in fact). But the only successful rewrites have been progressive rewrites, not big bang. It goes right along with this quote.
Our legacy system still has numerous known issues. It's like a hallway with lots of immovable obstacles and things sticking out of the wall. You eventually learn how to navigate the hallway and it becomes normal. But it limits what you can carry through it. So I have been approved and have started a progressive rewrite. This time I am doing a parallel system, and propagating data to the legacy system which is necessary to keep it functioning. Then migrating piece at a time to the new system and turning off that piece in the old system. That's the plan anyway.
When to rewrite
It is rarely worth rewriting simply to re-express the same solution on top of a different platform (framework, language). In that situation, all you really see are the upsides to the new platform. But it isn't until you get into it that you begin to see the new challenges. It often ends up with an equal amount of issues, but they are just in different places.
I usually find it worth a rewrite when the current code base / system constraints both restrict new kinds of features and resist being refactored. This ends up increasing the overhead of a new feature to be many times the cost of the feature implementation code itself. But the only way to make an improvement by rewriting is to first figure out a system/organization strategy (design, architecture) which is a better fit for your situation.
Well said, and I completely agree - re-writing exactly the same thing on top of different tech just because is begging for trouble.