This is often true and I stand behind this argument.
> The grass isn’t greener over there.
50/50. Many programmers get hyped for no rational reason but I've had objective successes on several axis when rewriting things from Ruby to Elixir, and C++ to Rust. And several half-baked web endpoints to plain old bash shell scripts as well.
On the other end, I've also rewrote two PHP apps to Ruby on Rails back in the day and for one of the both we basically ended up exactly where we were before, the problems included. That one was definitely a hype-driven rewrite and I regret doing it.
It can't be generalized. If you have actual pain point that you know will be addressed by a rewrite -- go for it. I know that for some of my work I am looking forward to migrating some Elixir code to Rust and I know for a fact it will help because that code is way too obscure and dynamic typing doesn't help. Beating it with the static typing stick will remove most of the FUD and shed light on many problems.
> Reporting bias
Sure. When your programmers are resume-driven, yes. If they are not, the reporting bias doesn't exist. Most of my career I've avoided resume-driven teams and individuals. I've seen reporting bias probably just 2-3 times over a 19 years of career.
> Honeymoon period
Agreed here. We the humans have this annoying tendency to conflate "it works well for the first N goals" with "it will work well and transparently, without surprises or problems, forever". Again, keeping objective here pays huge dividends.
> Snake oil
How is this relevant to software development? Maybe a consultant looking to rewrite your big app in a language nobody in the organization knows so he becomes un-fireable? If so, agreed. For everything else though, I am not seeing it.
> You are levelling the playing field for your competition
That's valid. Obviously a professional won't start a rewrite without management approving it though so I'd say it's a non-issue.
> Refactor, refactor, refactor…
That's unavoidable everywhere. Every now and then you have to refactor since business requirements are always evolving.
The ugly truth in our area is that you just have to smuggle refactoring in your other estimates. I am tired of trying to sell refactoring. I used many sorts of analogies -- you periodically make minor rearrangement in your house, you periodically need to maintain your car, you have to check your boots and clothes each season for whether they need repairs or replacements etc. Nothing works. People are like "yyyyyeahhh, those are true, but do they apply to code that's already working?" and the discussion is derailed.
> Modularise your codebase first
Absolutely! If your code isn't more or less organized then don't even start a rewrite -- you'll end up also writing a complete app spec in the process and that's a huge time sink.
> When to rewrite your codebase?
A book can be written about this but IMO:
1. No longer fit for purpose as the article says;
2. Business requirements cannot be well-enforced with your current app (as mentioned before, for some tasks static typing sheds a much-needed light).
3. Outsourcing?... Ehhh. Outsourcing can also be a huge liability. Sure you save some money now but you can very easily end up paying 5x that over the next several years. This can't be generalized at all and has to be mercilessly measured as much as possible.
> It will take a lot longer than you think.
This is often true and I stand behind this argument.
> The grass isn’t greener over there.
50/50. Many programmers get hyped for no rational reason but I've had objective successes on several axis when rewriting things from Ruby to Elixir, and C++ to Rust. And several half-baked web endpoints to plain old bash shell scripts as well.
On the other end, I've also rewrote two PHP apps to Ruby on Rails back in the day and for one of the both we basically ended up exactly where we were before, the problems included. That one was definitely a hype-driven rewrite and I regret doing it.
It can't be generalized. If you have actual pain point that you know will be addressed by a rewrite -- go for it. I know that for some of my work I am looking forward to migrating some Elixir code to Rust and I know for a fact it will help because that code is way too obscure and dynamic typing doesn't help. Beating it with the static typing stick will remove most of the FUD and shed light on many problems.
> Reporting bias
Sure. When your programmers are resume-driven, yes. If they are not, the reporting bias doesn't exist. Most of my career I've avoided resume-driven teams and individuals. I've seen reporting bias probably just 2-3 times over a 19 years of career.
> Honeymoon period
Agreed here. We the humans have this annoying tendency to conflate "it works well for the first N goals" with "it will work well and transparently, without surprises or problems, forever". Again, keeping objective here pays huge dividends.
> Snake oil
How is this relevant to software development? Maybe a consultant looking to rewrite your big app in a language nobody in the organization knows so he becomes un-fireable? If so, agreed. For everything else though, I am not seeing it.
> You are levelling the playing field for your competition
That's valid. Obviously a professional won't start a rewrite without management approving it though so I'd say it's a non-issue.
> Refactor, refactor, refactor…
That's unavoidable everywhere. Every now and then you have to refactor since business requirements are always evolving.
The ugly truth in our area is that you just have to smuggle refactoring in your other estimates. I am tired of trying to sell refactoring. I used many sorts of analogies -- you periodically make minor rearrangement in your house, you periodically need to maintain your car, you have to check your boots and clothes each season for whether they need repairs or replacements etc. Nothing works. People are like "yyyyyeahhh, those are true, but do they apply to code that's already working?" and the discussion is derailed.
> Modularise your codebase first
Absolutely! If your code isn't more or less organized then don't even start a rewrite -- you'll end up also writing a complete app spec in the process and that's a huge time sink.
> When to rewrite your codebase?
A book can be written about this but IMO:
1. No longer fit for purpose as the article says;
2. Business requirements cannot be well-enforced with your current app (as mentioned before, for some tasks static typing sheds a much-needed light).
3. Outsourcing?... Ehhh. Outsourcing can also be a huge liability. Sure you save some money now but you can very easily end up paying 5x that over the next several years. This can't be generalized at all and has to be mercilessly measured as much as possible.