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.
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.