[sdeframond]

Sometime the best way to why a (Chesterton's) fence is blocking the road is... to remove it and see what happens!

Sorry, not really an answer to your problem. But I feel you, this is a genuinely hard problem.

Keep in mind that, pretty often, the reason something is the way it is comes down to "no real reason", "that seemed easier at the time" or "we didnt know better". At least if you don't work on critical systems.

[4star3star]

As a counter point, it may be quite subtle and hard to notice what goes wrong when you remove something to see what happens. Imagine you see a large sql query that has a bit of logic that doesn't make sense to you. If you go change it without knowing why it was that way, and users keep on using report output from that query, who is going to notice when they get 982 records in their report instead of 983 one day? It's easy to spot when erroneous data APPEARS, but it's a lot harder to notice when valid data DISAPPEARS. Oh, they really did have a good reason to use outer apply instead of cross apply, there. Oops.

[sdeframond]

That's a good point indeed.

For this particular case I like to put in a comment next to the weird thing that seems out of place. It can be a short summary and the link to a specific ticket for example.

Also, tests.

Edit: actually id like to emphasize the need for tests. One must be able to refactor code without fearing to break undocumented requirements.