Yes, :100: :100:
I have seen this happen so many times. It's a vicious cycle of horribleness. The same people always seem to get the new development also because they were "so successful with the last launch" and the people maintaining it are perceived as slow and ineffectual because it takes so long to iterate (ironically because of the person who looks like a rock star).
I feel very lucky in my career that I don't have to put up with this anymore. If I could go back in time I would just tell myself to quit and find a more compatible company instead of suffering for years under a self-destructive system that punishes people like me. Since breaking free from that and starting my own projects, I've been very successful.
I don't mean to imply that I always write perfect code, or even great code, because surely I don't. I do expect some things to be throwaway that end up staying around. But doing something correct rather than fast in general is a much better long term strategy. Vary as necessary (but only when necessary).
Of course not. I may enjoy cleaning up my own messes, but not one that someone else has foisted upon me. The problem with teams like this is that the fast-movers are long gone by the time the impact of their expediency is being felt. They benefit from the accolades of a launch while shirking the responsibility of operating a product.
> In this case, why do you do it?
Because the product sucks and needs to be improved, but it is an unimprovable mess because everything was done expediently instead of well, some of which needs to be fixed in order to move forward. A lot of the hard work at this point is in figuring out the best pragmatic balance of what to fix vs. what to leave alone. A little forethought could have saved a lot of post-facto toil.
I do like iteration, doing things in small iterative chunks. But that is not the same as putting out a huge mess and hoping someone comes along who enjoys cleaning it up.