I've been on the other side of this and seen too many teams neglect to fix even the simplest and most frustrating bugs in a system because they're going to rewrite it "in the next six months". Usually the rewrite is still going years later, and the actual code used in production is left to rot, holding back other teams as well.
It happens when you have a lot of new people who refuse to work with legacy code (which is anything over 2 years old), trivialize the complexity of the existing system (because they don’t understand a tenth of what it does), go create a sub par replacement with tons of people and years of work (that ends up coupled to the legacy system anyways), and now the company has two systems to maintain requiring double the resources as before. When everyone gets fed up and leaves, the cycle will start again. Our system is about four levels deep now. It’s the f’ing matrix.
Most of the new development I've worked on has been terrible, I attribute it to agile and the two week sprints churning out non stop MVP code that's technical debt from day one.
Can you blame them? These are the same teams who typically refuse to adopt practices that would allow them to create tests and we'll encapsulated designs. So inevitably the team is once bitten twice shy about breaking production. Why be the poor bastard who introduced anything but the tiniest bugfix?
I definitely agree it's a matter of incentives. Even in an environment with a now healthier quality culture, fixing bugs to bring an old system from 70% functionality to 100% is typically a career dead end.
It's much better to leave it broken and build a new system with 105% functionality so you can take credit for the whole 105%.
And typically, optimists that we are, it seems like completely reimplementing the original functionality will be "trivial" compared to merely trying to understand how the existing solution works.
