A developer added a comment: // TODO: fix this later.
Five years later, the comment was still there. The developer had left the company. The code worked.
The senior developer asked the team, “Whose TODO is this now?”
No one answered. The senior added, “And what does it mean to fix something that does not know it is broken?”
Dwelling in the Question
Every codebase carries these small promissory notes: TODO, FIXME, HACK. Each one is a message from a past self to a future self, written in a moment of awareness that something could be better, paired with a decision that now was not the time. The comment in this koan outlived its author’s tenure. The promise remained, but the person who made it was gone. So the senior developer’s first question cuts to ownership: whose TODO is this now? A promise without a promiser is a strange artifact. It belongs to no one, and therefore to everyone, and therefore, in practice, to no one again.
The second question goes deeper. The code works. It has worked for five years. Users are served, tests pass, revenue flows. The only evidence of brokenness is the comment itself, a judgment frozen in time by someone whose standards, context, and constraints we no longer know. Was the code truly flawed, or did the original developer simply see a more elegant shape it could have taken? Elegance unrealized is not the same as a defect. If we deleted the comment today, would the code become whole? If the code has caused no harm in five years, was it ever broken, or only judged?
This is not an argument for ignoring technical debt. Some TODOs mark genuine hazards, and those deserve tickets, owners, and deadlines rather than comments. The teaching is about discernment: the difference between what is actually broken and what merely fails to match an ideal we once held. A mindful team periodically reads its TODOs the way one might read old letters, asking of each: is this still true? Is this still ours? Sometimes the fix is code. Sometimes the fix is a ticket. And sometimes the fix is deleting the comment and releasing a promise no one alive ever made.
The next time you write “fix this later,” pause. Ask whether you are recording a real obligation or simply easing the discomfort of shipping something imperfect. If it is an obligation, give it an owner and a date. If it is discomfort, consider letting the code be what it is. Later, as this koan reminds us, is a place where promises go to outlive the people who made them.