[atjoslin]

The reason most people tell me they use todos is, "you can't do everything up front."

I agree, but I hate TODOs. They're the worst form of keeping track of technical debt.

Just open a ticket! I like to have a tag/label called "debt" that I put these "TODO, bad implementation" type of problems under.

That way at least it's tracked.

[aiiane]

A preferred method for doing this at Google is to open a bug, and then leave the TODO in the code with a reference to the bug number. This has the advantage that if someone comes by to refactor the code later, they'll have the chance to go look at the bug (possibly taking it and working on it, possibly resolving it as obsolete if the original issue no longer applies, etc).

Having the two-directional link between the bug and the code is quite useful, especially for what is probably the most frequent use I've seen for TODOs: "We could do this better, but the better way is blocked on circumstances beyond our control. Once those change, revisit this."

[bArray]

I actually like that - perhaps that allows you to implement blocking as well, for example: "TODO: X cannot be improved until Z & Y is complete.".

The projects I work on tend to have a very quick life cycle, so there isn't even a ticketing system in place other than the occasional post it note. There just isn't the time and the team is tight.

[flukus]

This is my preferred method, but if there is any sort of bureaucracy in place around creating a ticket then it's not a solution that gets used.