My feeling is that rewriting is used as blunt weapon when the developer lacks the inclination or skill to learn what was written before. I’m been guilty of this.
That certainly happens but rewriting also happens because what is already available doesn't get the job done and can't be customised so it does.
One of the curses of modern software development is that so many of the resources we rely on are highly opinionated. We have frameworks and toolkits and scaffolding scripts and proprietary formats and convention-over-configuration to do things that could have been done with flexible, self-contained libraries and open standards.
These opinionated resources are often easier to create but they can cause great harm over time as a small application that got a boost from using them initially grows into a large application with changing requirements. Maybe those requirements can't easily be met if nothing composes and nothing can be adapted and each dependency becomes a fight between the direction its developers choose to take it that might not be right for the application and the need to keep updating because the developers don't want to support older releases of their code with essential bug fixes and security updates any more.
In this kind of environment, it is hardly surprising that some teams prefer to build things in-house even if they are reinventing a few wheels. It is sometimes the only way to retain control of your own code or to regain that control after the technical debt becomes overwhelming.
Or the time. When you've been given a hard one-week deadline to produce something, you can commit to writing something that works with a lot more confidence than you can commit to figuring out somebody else's piece of garbage.
Most rewrites I’ve seen are huge system replacing projects that came over budget and often missed requirements. I’m not saying there are no legitimate reasons for rewrites. But when people bring it up, I think you need to ask a lot of questions.
I've advised engineers to rewrite code before, mostly for resume building to help jumping ship to somewhere better.
If a company doesn't have a stock-based comp and sticks to prevailing wages/CoL there's no incentive to help the company succeed. Especially with non-technical management, the best thing to do for ICs is often to aggressively rewrite (in the language that's trendy right now and that better companies use) and get promoted by showing off a significant output. Then jump to a better company having spent a year training on their stack at the previous company's expenses.
Most rewrites I saw was "wow, this Java code from the old team is a mess, let's rewrite it and, in a couple years, the new devs will think the same about our rewrite."
I think you're onto something there. It's hard to understand code. So maybe the best way to accomplish that is to rewrite it. That way you will have inhouse people who understand and can maintain the software your business is running on. Once those people are gone it's time for the new recruits to rewrite it again. It's a continuing process.
One of the curses of modern software development is that so many of the resources we rely on are highly opinionated. We have frameworks and toolkits and scaffolding scripts and proprietary formats and convention-over-configuration to do things that could have been done with flexible, self-contained libraries and open standards.
These opinionated resources are often easier to create but they can cause great harm over time as a small application that got a boost from using them initially grows into a large application with changing requirements. Maybe those requirements can't easily be met if nothing composes and nothing can be adapted and each dependency becomes a fight between the direction its developers choose to take it that might not be right for the application and the need to keep updating because the developers don't want to support older releases of their code with essential bug fixes and security updates any more.
In this kind of environment, it is hardly surprising that some teams prefer to build things in-house even if they are reinventing a few wheels. It is sometimes the only way to retain control of your own code or to regain that control after the technical debt becomes overwhelming.