>Eventually you have to apply a small stimulus (incremental change) and observe the response. In any sufficiently complex system this is probably true. Often t

>Eventually you have to apply a small stimulus (incremental change) and observe the response. In any sufficiently complex system this is probably true. Often there's a reason for some thing being there, and that reason is often enough a workaround for an issue in an external library. Then the library gets updated, but the workaround remains. I've observed this often enough. I try to add a comment whenever I do this linking to the issue on the external repo if possible, so that later on you can check if it's still needed. But this is not fool proof and not everyone will leave breadcrumbs. The breadcrumbs might also be eaten in the meantime by some merges and refactorings. In the end you're often left with a useless workaround, the person that made it is not in the company anymore, and there's nothing to observe for why it's necessary. If you don't want your system to eventually collapse under its own weight, sometimes you have to go for a risky refactoring. Doing it incrementally mitigates the risk.