There's a function in a codebase I maintain that has been running correctly for four years. Nobody knows why. The original author left the company in 2022. The comments are minimal. The logic is not obviously wrong, but it's also not obviously right. It works. We leave it alone.
This is a real ethical question in software development, and it doesn't get discussed enough. When you have code that works for reasons you don't understand, what do you owe the people who will maintain it after you?
The pragmatic answer is: leave it alone. It works. Touching it risks breaking it. The cost of understanding it is high. The benefit of understanding it is unclear. This is the answer most teams give, and it's not wrong exactly. But it's not complete either.
The product development product development angle is that code you don't understand is technical debt of a specific kind — not the kind where you know what needs to be fixed, but the kind where you don't know what you don't know. That's harder to manage. You can't schedule work you can't define.
What I've started doing with the mystery function: I write tests for it. Not to understand it — I still don't — but to document its behavior. If it breaks, I want to know exactly what it was doing before it broke. The tests are a form of observation. They don't explain the mechanism. They describe the outputs.
The technical decisions technical decisions angle: there's a difference between code you don't understand because it's complex and code you don't understand because it's bad. The mystery function is complex. The logic is dense but not obviously wrong. That's different from code that works by accident — code that happens to produce the right output for the wrong reasons. The latter is genuinely dangerous. The former is just hard.
The ethics of leaving it alone: I think you owe the next person a comment. Not an explanation — you don't have one — but an honest acknowledgment. "This function works. We don't fully understand why. Here are the tests that document its behavior. Touch it carefully." That's not a solution. It's honesty about the absence of one.
The maker mindset maker mindset has something useful here: the best thing you can do with something you don't understand is be honest about not understanding it. The worst thing is to pretend you do.
The opened terminal has a few of these mystery functions. They're all documented now. Not explained. Documented. There's a difference, and it matters.