[Groxx]

It was just to ensure it wasn't forgotten. If it's "long term", stick it for a year out or something, it's fine. Truly timeless? Year 2999 works pretty well, or just don't use "todo" because it apparently isn't gonna happen.

We fairly often used it for stuff like "X should be upgraded to fix Y by now, see if this hack is still necessary". If was not, just push it out and check again then. Or do whatever else might be necessary since it didn't meet expectations.

I've encountered many codebases with todos that are years old, sometimes authored by people no longer at the company. A date ensures these aren't lost forever. You can always just push it another year out.

[marcosdumay]

If your TODO is forgotten, it's overwhelming likely that it wasn't very important.

You annotate the code to save some context for the next time you read it. A TODO is basically an anchor so you know where to come back as soon as you finish that requisite you are doing now. If you get anxious about deleting them, you may need to rethink your process, because it's not a suitable place for the kind of information you get anxious about losing.

[Groxx]

>If your TODO is forgotten, it's overwhelming likely that it wasn't very important.

Sometimes, but not always. We deleted the ones that were not, and finished the ones that were.

As far as noticing these by hand: my current project is about 600,000 lines of hand-written code, not including several libraries we also author and use in it, nor other projects I'm also heavily involved in. I haven't even looked at all the code yet, much less do so on any regular cadence. Forgetting is something you plan on and address up-front, not something you just let happen.

[arinlen]

> It was just to ensure it wasn't forgotten.

Why don't you just add a ticket in a ticket backlog, then?

[ParetoOptimal]

Most of the time it's not possible to trust items you add to the backlog related to tech debt will actually get done.

Why make lists that will never be completed?

Or put another way, there is no pain that can't be avoided by ignoring the backlog.

You can only ignore these TODOs until your build fails, then you have to reflect on whether to do them, push them into the future, or delete them.

I think this works because it really makes backlog grooming a group activity where everyone is involved, so everyone feels they have a say in setting priority.

[shikoba]

You can grep for todo in your codebase. It will list them.