Have you ever worked with a project that had hundreds and hundreds of @todos in the codebase?
What is the first thought that comes to your mind when you see Found 786 items in 492 files?
Would you like them to go away and let you be?
There are two types of developers when it comes to TODO. Actually, TODO is not applicable to developers themselves. TODO is about the team. So...
Green cult
This team places TODO almost everywhere when it looks suspicious, complicated or anywhere similar to tech debt. It ends up exactly as mentioned in the intro - huge amount of TODOs that likely will never be “toDone”. The reason for that is quite simple: when you do something wrong on an everyday basis it becomes normal.
Red cult
This team deprecates TODO usage because see the green cult. Instead, this team creates a ticket in jira, youtrack or any other tracking system. It is said that this approach is effective because tickets sooner or later will be resolved and won’t be lost in a huge codebase. This team often has problems with time management or a business owner who does not care what tech debt means.
TODO culture
As you might have guessed there is more. The green cult ends with tons of useless TODOmarks that no one takes seriously. It does not work if your team does not have proper agreements. That is why red cult also does not work. It ends with exactly the same result but instead of the code it will reside in the tracking system.
Pretending that there is no issue(TODO) also does not solve an issue.
Talk with your team. Make some agreements. Make it work.
TODO is a tech debt and leaving it in the code will burden your team later.
Here is a simple agreement that may really help you to resolve it and make a healthy TODO culture: whenever you work on the code that contains TODO, try to resolve it too.
Actually, this rule is not something new - it is a close relative of boy scout rule presented by Robert Cecil Martin (aka Uncle Bob) in the clean code book.
Exactly because of this approach it is better to use TODO in the code instead of an external system. Meaningful TODOs make a huge difference here because it saves time for the developer who is not familiar with the case mentioned. It has to give some context to work with.
Remember, it won’t work if the team does not care. No matter how much effort you put in.
That is why before you start discussing the culture you have to be sure that you are talking with interested people.