Sunday, December 6, 2009
ToDo or Not ToDo - that is the question.
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 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.
Posted by David Koontz