"Think of a person that has messy house. This person does not have practice to keep things clean and in order. The person decides he/she will fix the issue by building another house and burning the old one with all belongings. The result is predictable."
I believe your unstated epilogue is supposed to be something like "Rather than build a new house, it is best to learn how to take care of the one that you already have." Great. So let's suppose that happens. Now the team has a new skill. They've learned how to be organize their code and fix the problems in the code. So should they incrementally improve the code, or should they do a complete re-write? Your analogy does not stretch that far into the future.
I agree with this, and I've had the same experience:
"I found that most of the teams I met stopped or indeed never really had any practice of constantly diagnosing and improving their process and application. This is usually the cause why the application is in bad shape but more frequently than not the team will blame the organization, predecessors or constraints like old technology they are working with."
My sense is that what these teams need is new leadership. It doesn't really matter if their code is written in Fortran or C or Javascript or Go, what they need is good quality new leadership. Once they get that, their situation will improve. However, the new leadership needs to have the freedom to take the team in the direction of those skills and experiences that the new leadership has gathered over their lifetime. If the new leadership has a lot of experience in Ruby On Rails, then a complete re-write to Ruby On Rails can be justified, because if the new leadership is good, then they will produce something good in Ruby On Rails, and it will be better than what the old organization had before.
And indeed, I think many real life re-writes happen because of exactly this set of circumstances.
"Think of a person that has messy house. This person does not have practice to keep things clean and in order. The person decides he/she will fix the issue by building another house and burning the old one with all belongings. The result is predictable."
I believe your unstated epilogue is supposed to be something like "Rather than build a new house, it is best to learn how to take care of the one that you already have." Great. So let's suppose that happens. Now the team has a new skill. They've learned how to be organize their code and fix the problems in the code. So should they incrementally improve the code, or should they do a complete re-write? Your analogy does not stretch that far into the future.
I agree with this, and I've had the same experience:
"I found that most of the teams I met stopped or indeed never really had any practice of constantly diagnosing and improving their process and application. This is usually the cause why the application is in bad shape but more frequently than not the team will blame the organization, predecessors or constraints like old technology they are working with."
My sense is that what these teams need is new leadership. It doesn't really matter if their code is written in Fortran or C or Javascript or Go, what they need is good quality new leadership. Once they get that, their situation will improve. However, the new leadership needs to have the freedom to take the team in the direction of those skills and experiences that the new leadership has gathered over their lifetime. If the new leadership has a lot of experience in Ruby On Rails, then a complete re-write to Ruby On Rails can be justified, because if the new leadership is good, then they will produce something good in Ruby On Rails, and it will be better than what the old organization had before.
And indeed, I think many real life re-writes happen because of exactly this set of circumstances.