ToDos Gone Wild!
Writing ToDos in your code as a reminder that some needs to be fixed is almost considered as a holy grail (universal best practice) to manage technical debt. No one seems to talk about issues using ToDos.
While I’m not against ToDos, I think, in some cases developers build a tendency that:
I’ve put a ToDo, I’ve done my job and now I can move on.
I’ve a problem with this behavior. In some cases there might be tangential work that is worth marking as a ToDo, but in lot of cases what should be fixed now, gets pushed off for later. Slowly the code quality keeps dropping and technical debt sets in.
Building on this thought process, ToDos can encourage wrong behavior of not fixing stuff at the source and pushing them in the future. It’s kind of the broken window syndrome:
There are so many ToDos in this code, one more won’t make a big difference.
Even if someone wants to fix some, looking at the sheer numbers, the person can get intimidated.
Some teams have so many ToDos in their code, that the team develops immunity towards them by now (it losses its value).
So please think before adding your next ToDo.
