If you don't understand how and why, it's broken.
Sometimes its either ship something broken or lose your job.
If you're gonna do that it should only be after sending a very blunt CYA email.
It's a load-bearing function.
We have no idea why it's important, just that it is critical to everything functioning.
One of my favorite Simpsons lines, the load hearing poster
I feel like the "we don't know what this function does" meme is kinda bad. There's no reason beyond maybe time crunch why you shouldn't be able to dissect exactly what it does.
Despite this, the notion of a load-bearing function is still very relevant. Yeah, sure, you know what it does, including all of the little edge case behaviors it has. But you can't at this time fully ascertain what's calling it, and how all the callers have become dependant on all the little idiosyncracies that will break if you refactor it to something more sensible.
It has been several times now where a part of my system of legacy code broke in some novel fantastic way, because two wrongs were cancelling out and then I fixed only one of them.
What if all the tests pass?
If the tests pass, then everything is fine... Unless we expected the tests not to pass...then it's time to burn the codebase down and try again after a long vacation to clear our heads.
Of course, I'll usually settle for fixing the test suite after a long weekend. But in my heart, I'll know what I should have done...
If the tests don't give any insight into the functionality it is testing, they are probably not the best tests.
Let it Be? No, no. Let it Haiku.
