It's a hard balance to strike. On one hand, the code is ugly and difficult to understand, but it has that ugliness for a reason, it's solving edge cases that yo

It's a hard balance to strike. On one hand, the code is ugly and difficult to understand, but it has that ugliness for a reason, it's solving edge cases that you don't remember and a rip and replace is always expensive and no guarantee it won't devolve just as quickly. How do you strike the balance of the dev team wanting to fix unbroken code for long term health, and investing in new features that grow the business. Personally, I am biased towards encapsulation as a means to handle a lot of these types of tech debt. Wrap the old stuff in an orchestration layer and build new features with the orchestration layer in the middle. It's a bit of sweeping the dirt under a rug, but it also gives you a real solid base for later coming back and cleaning up the ugliness if it's really needed by giving solid contracts between the consumers and the orchestration layer and the legacy system and the orchestration layer.