Why can’t the existing code just be adapted to the new requirement? Code is supposed to be mallable. But perhaps the code was designed too rigid to support changing requirements. In that case you will have exactly the same problem after the rewrite, next time requirements change again.
It depends a little, sometimes companies (especially start-ups) pivot quite substantially - With a Fintech that I've worked with from the beginning (which went through ups and downs, but ultimately ended up quite successful) we started issuing debit cards and pivoted to loans. At some point we just needed a different app that was properly written for the use-case that we ended up serving. It's like the parent said, the re-write was done by the same team (mostly) - those were 4 busy months but it ended up quite successful and imo it was worth it at the end. And I have to admit I was actually very critical of the re-write approach initially..
Well, you kinda answered yourself: code is supposed to be malleable, but sometimes it isn't.
Even when it follows trends and best practices, you might end up with non-malleable code. Perhaps especially when you over-do trends (eg: metaprogramming, 15 years ago) or best practices (design patterns, 100% unit test coverage, etc).
You will only have the same problem if you fail to solve the malleability problem.
If developers have learned to write mallable code, they are also competent enough to improve existing code by refactoring, since this is two sides of the same coin. Maintaining code is how you learn to write maintainable code, after all.
I dont know how code could be too rigid to change by a competent developer. If it has bad abstractions just rip them out. If it is unclear and badly documented, you will have the same problem when rewriting.
> I dont know how code could be too rigid to change by a competent developer.
This is an unfair characterization of what I said. I never said it was impossible to improve, just that it is too difficult and costly.
Whether a rewrite is warranted or not, is up for each individual team to decide, we shouldn't leave this decision to dogma. I have run into some cases where a rewrite was the correct thing to do, and it did pay off.
> If it is unclear and badly documented, you will have the same problem when rewriting.
A program being unclear and undocumented on the development side doesn't automatically means it is unclear and undocumented on the business/product side. There is also the possibility of changing workflows or simplifying functionality.
A lot of people in this topic are mentioning full reuse of tests, but not all software rewrites should be done in a vacuum by the development team without continuous input from the rest of the business.
EDIT: And there's another case: sometimes the app itself is actually quite simple, but understanding things from the code-side is very difficult. I'm currently finishing a rewriting of one of those: the code is too large and unmanageable due to accumulated cruft (it is difficult to know what can be removed), but some product managers, business owners and business intelligence people have an amazing understanding of the database (better than some past developers, actually), and the database is simple, so they can verify if the new version is correct and even draft requirements based on it.
