I don't get the hate that TODO comments get (edit: in this comment section, not in the original article). They signal that the person who wrote the code has recognised there is a potential issue, has deemed it not relevant enough for it to be solved right now and wants to summarise the issue in the comment.
If you disallow TODO comments, you will lose that context, or at least it won't be easily searchable anymore. Issue trackers are not a solution because:
- they create too much friction. A developer that is short on time might add two or three comments to suboptimal code rather quickly but would likely not bother dealing with a clunky UI like JIRA, having to write detailed descriptions referencing the exact place of the code, filling out 20 fields and then being hounded by a PM who (rightfully) doesn't understand what "implement foobar() in linear time" or "make Frobulator thread-safe" means.
- Comments are right next to the code, issues are not. I see people pointing out that comments can get out of date, but so can issues in an issue tracker.
- IMO, "refactoring tickets" tend to be the worst tickets, they're rarely fun to work on, they don't include the context for why the refactoring might be necessary or what the best way to evolve the code is, and if someone else is assigned to the issue than the author of the ticket, they might not even understand the intended refactoring. A comment is much more light-weight and optional and anyone who touches the code can read it and decide whether it makes sense to fix it. It's also almost impossible for a PM to know how to prioritise refactoring tickets. IMHO, unless we're really talking about refactoring entire systems, refactoring should preferably be done continuously whenever the need arises, i.e. "first make the change easy, then make the easy change".
- of course, code shouldn't be merged if there are glaring issues that don't implement the feature correctly / could break important things. It's the responsibility of the developer and the reviewer to make sure that this doesn't happen, regardless of whether there are "TODO"s or not.
Dodging an issue tracker is, IMO, one of the clear benefits of TODOs (or FIXME, HACK, BUG, and family). Especially in low-trust teams or whenever there's a need to avoid the sorts of politics that can arise between roles.
Refactoring tickets are terrible for all the reasons you point out. PMs will essentially never prioritize refactor work over new features unless pressured to, and if so, the work more often than not gets assigned to newer hires and junior devs, whereas a TODO is actually more likely to get picked up by a curious and intrepid newcomer when they're actually ready for it. Should said newcomer stumble across it before they are ready, it can also be a signal that they ought to reach out to a more experienced developer to ask some questions. For devs, refactor tickets may be useless overhead: in time spent writing, time spent defending, time spent estimating, etc. And in return, there's little glory or praise achieved in working on them; tracking too much time on refactor tickets may even attract negative attention from management. Then good luck if your QAs and agile leads are suspicious of any unit of work that a new test plan can't be written for.
A good TODO is sometimes just how the sausage is made.
The author is not saying TODO comments should be disallowed or stopped entirely, and explicitly states that he's not suggesting "use an issue tracker instead".
His recommendation is to use meaningful alternatives, e.g. FIXME, HACK, BUG, etc.
If you disallow TODO comments, you will lose that context, or at least it won't be easily searchable anymore. Issue trackers are not a solution because:
- they create too much friction. A developer that is short on time might add two or three comments to suboptimal code rather quickly but would likely not bother dealing with a clunky UI like JIRA, having to write detailed descriptions referencing the exact place of the code, filling out 20 fields and then being hounded by a PM who (rightfully) doesn't understand what "implement foobar() in linear time" or "make Frobulator thread-safe" means.
- Comments are right next to the code, issues are not. I see people pointing out that comments can get out of date, but so can issues in an issue tracker.
- IMO, "refactoring tickets" tend to be the worst tickets, they're rarely fun to work on, they don't include the context for why the refactoring might be necessary or what the best way to evolve the code is, and if someone else is assigned to the issue than the author of the ticket, they might not even understand the intended refactoring. A comment is much more light-weight and optional and anyone who touches the code can read it and decide whether it makes sense to fix it. It's also almost impossible for a PM to know how to prioritise refactoring tickets. IMHO, unless we're really talking about refactoring entire systems, refactoring should preferably be done continuously whenever the need arises, i.e. "first make the change easy, then make the easy change".
- of course, code shouldn't be merged if there are glaring issues that don't implement the feature correctly / could break important things. It's the responsibility of the developer and the reviewer to make sure that this doesn't happen, regardless of whether there are "TODO"s or not.