This is one of those big challenges. Deciding when to tear something out that is subpar to replace it. I'm going through this now with code inherited from other

This is one of those big challenges. Deciding when to tear something out that is subpar to replace it. I'm going through this now with code inherited from others and stuff I've written in the past that I think I can do better. As a lead it's my job to "prune the tree" of code and guide it but I can't just roll over every decision ever made simply because I want something better. It's never perfect. So what I do is for every chunk of code I think needs to be replaced or solidified I ask myself first how it will impact my schedule, how it will impact other coders as they do maintenance, if the end goal is a better user experience, and if so does that serve the business? From answering these questions I can determine if we should make a change now, or if we want we can defer the change to a specific place in our timeline and plan it out. This has worked well for me in the past.