What does a TODO tag in your code say about you as a developer?
When is a TODO not appropriate - is it every appropriate to postpone work that you recognize, but just don't want to deal with now? Is procrastination a trait that we encourage or discourage?
I posit that quality code has very few if any TODO tags. That there is a inverse correlation between the percentage of TODOs in a code base and the quality of the code.
Srikaran Reddy had this argument to make:
TODOs present in code may be indicative of the quintessential engineer: one who can distinguish between what is required at the moment versus an ideal, or potential future requirement, that is of relatively lower priority. The term 'sine qua non' comes to mind. This is especially true when maintaining inherited code. On the other hand, a TODO could represent some sloppiness. There are different flavors of TODOs that need to be factored into this argument.
The good thing about TODOs is that they are easily tracked, and after a simple search, could be transformed into whatever ticketing or bug/issue tracking mechanism the team is using.
One might argue that a TODO is simply an item in your uncommitted backlog that happens to be noted in your code.
The good thing about TODOs is that they are easily tracked, and after a simple search, could be transformed into whatever ticketing or bug/issue tracking mechanism the team is using.
One might argue that a TODO is simply an item in your uncommitted backlog that happens to be noted in your code.
Srikaran may be the quintessential engineer, so I respect his point. Are there flavors of TODOs just like there are flavors of quarks? Yes I think there may be, but how do we tell them apart? Let's put a flavor tag and annotation after the TODO comment.
Here's an idea - allow the IDE to grow the icon/font associated with a TODO by the interest rate for the technical debt it represents (I suggest prime rate + 10%). Therefore after several years of a legacy TODO the icon or font would be 3X the normal code text.
TODOs in code do provide an easily searchable tag, it is a nice and neat way to decorate the code with more work to be done. In the case of the bug tracking system the TODO represents work needing to be done in two places - the code base, and the entry in the bug tracking system - neither of which were done by the addition of the TODO.
The argument for a TODO representing a backlog item is weak, but interesting rationalization. I think the purpose of the backlog in Scrum is to be a visible prioritize list of work. The TODO fails on both attributes of this list type. It is not visible to everyone on the team, especially the Product Owner who is responsible for prioritization.
Comments