views:

113

answers:

4

The site I work with on a day-to-day basis has its share of shortcomings and we often make design decisions to "get us by right now" with the intention of fixing those up later.

I've found that making the time to actually go back and fix them, let alone remembering what the full list of to-do items is can be challenging at best.

Can you recommend any tools, resources or tricks that help you effectively manage your technical debt?

+4  A: 

You could use any bug/task tracking software, eg see this stack overflow question: http://stackoverflow.com/questions/101774/what-is-your-bug-task-tracking-tool.

Of course, a simple solution is just to have a text file called TODO or similar. It's low maintenance, and particularly appropriate if it's a WORN file (write once, read never).

Peter
A: 

If it ain't broke, don't fix it

This seems to be the policy you are currently following. From my experience, it works most of the time.

mouviciel
"If it ain't broke, don't fix it" is quite different to saying "If it's working, it doesn't need attention". The maintenance overhead, stability or some other unseen issue behind the scenes should not be ignored indefinitely. I think it's better to ensure that you're completely confident and even proud of the work you turn out. To that end, I want to ensure I go back and address the issues I know I've left outstanding.
Phil.Wheeler
-1: This policy works until you have to go back in and modify the spaghetti code. Refactoring to "leave the campsite cleaner than when you arrived" backed by tests to insure that you aren't breaking anything is an accepted practice.
TrueWill
A: 
  • Unit testing
  • Refactoring
  • Continuous Integration
  • Planning (XP, Kanban, etc.) to avoid adding more technical debt
  • Standards
  • Code reviews
  • Project retrospectives
  • Static analysis tools (like FxCop) integrated with the CI build or check in process

I'd say TODO comments in the code, but my experience has been that developers generally ignore these.

TrueWill
A: 

I would suggest you add an item in your product backlog whenever you deliberately incur technical debt. This way, it is possible to consciously spend time during each iteration.

David Segonds