Tracking Technical Debt in ReSharper

I love ReSharper. It's purely platonic. After all, I am a married man. But it's always there for me: my trusty little sidekick, my own personal Sancho Panza. Its array of helpful features is truly impressive: it enhances editing capabilities; it helps me organize the classes in my projects; it cleans up my code for me; it tells me when I'm missing references; it offers suggestions for more readable conditional statements; it's a floor wax, a dessert topping, and a gentle laxative.

One of my favorite ReSharper features is the To-do Explorer. It scans your code base filtering on comment tags you define ("//TODO", et al) and gives you a clickable sorted list of those items. It's nicer than the VS TaskList in that you can sort the results in different ways (my favorite being by namespace and type), and you can copy the results to the clipboard or save them out to a text file.

Since swinging into TDD at our office in the last few weeks, we've started taking the idea of Technical Debt very seriously. As we're working through our implementation, we recognize that there are some deadlines which will force us to make some compromises on design decisions. That's ok as long as we don't forget to go back and re-work those things later. We've found that an easy way to track those things is to mark them with the comment tag "//DEBT" and set up a ReSharper To-do Explorer filter for that tag. Then when we're planning our next phase, we've got a sortable, printable list of items we know we have to prioritize into the project plan.

Taking that idea a bit further, we decided to standardize on the following three code comment tags and create ReSharper To-do Explorer filters for each:

1. //HACK == a HACK is something we put in place knowing it was wrong to begin with, and knowing it has to be taken care of as quickly as possible.
2. //TODO == a TODO could be anything that we need to complete by the end of the current iteration.
3. //DEBT == a technical debt is a calculated decision to complete a feature in this iteration using a design we know we will need to refactor in a future iteration. 

When we take a look at To-do Explorer, we get something like this:

So before the end of the current iteration, we know we need to clean up our HACKs and TODOs.  And at the beginning of the next iteration, we can throw the DEBTs in with the requirements to be prioritized and worked into the iteration plan.

I'm sure there are other ways to track technical debt that offer more info, but this is a quick, easy, and cheap way.

Share this post :