9 ms·

What's the advantage of throwing away context that could be useful in the future? I've taken ownership of codebases with technical debt before, and when modifyi

What's the advantage of throwing away context that could be useful in the future? I've taken ownership of codebases with technical debt before, and when modifying the code for something time-sensitive, I often annotate issues with the code whose solutions (usually refactoring) can't be fit into the timeline of the current project. I (or others) can then take advantage of these annotations when I have time to dedicate to refactoring, or in many cases, fit the refactoring into feature work. The fact that a portion of the design groundwork has already been done (as captured by the TODO) makes it easier to fit in the cleanup work. IME, this approach leads to much more rapid improvement of legacy codebases than your description of do-it-now-or-forget-about-it.

sedatk 7y ago
You don't throw it away, you put it in the issue tracker where it can be prioritized, tracked and categorized. If it's not worth of the issue tracker, it shouldn't be worth of a TODO either.
- danShumway 7y ago
  Eh. This is a company culture thing that depends on how you use your tracker. At many companies, issue trackers are not used for things like "refactor this method". They're used for user-facing stories or architectural projects, and they're transparent to managers who don't want them cluttered with non-user facing stories. I've run into managers who didn't want any TODOs in code, they wanted everything to go through the tracker. I've also run into managers that told me to stop putting everything into the tracker because they didn't know how to prioritize a random method refactor, and they felt like that information wasn't relevant to their scheduling. I don't have a strong preference, but I lightly lean towards preferring the latter strategy. Issue trackers are slow. They are so slow, and so cumbersome, and so hard to organize, and you waste so much time linking to code files that get refactored or moved around so the context is lost. The nice thing about a TODO in code is if the method gets deleted, the TODO also gets deleted. When you're refactoring code, you don't have to go search an issue tracker and think, "wait, is there anything related to this refactor I need to update?" If documentation is code that never gets compiled, issue trackers are like dynamically linked libraries that never actually get compiled or linked. It's very hard to keep them up-to-date; it's very hard to preserve the references. For smaller, single-person independent projects, I don't use issue trackers. I use high-level todo lists, and all of my notes are in code next to the context they're being used for. This is because an issue tracker is just bloat for those kinds of projects.
  - Jach 7y ago
    I think it's less of a company culture thing and more of a local team preference thing. If the ICs on a team are united, managers are often willing to change things a bit from how they're used to it. It could be just as simple as prefixing a "[Trust]" tag to items that are important and have some priority within developer minds, but product management has no opinion / ability to form an opinion apart from earlier they've agreed on a general "[Trust]" bucket to account for such things. This lets them be filtered out as needed. Worst case, a united team can have a private issue tracker and beef up their estimates to management to account for work management doesn't want to hear about but needs doing nonetheless. If you don't have either a united team or managers willing to move at all, or even work with ICs collaboratively, you have bigger problems than what you do with TODO et al. If I were in such a situation I'd still use an 'issue tracker' (maybe a local text file) 9 times out of 10, while also looking for a better job. Issue trackers are slow and I have to work with one of the slowest (it was built in-house on top of a core product never meant for such a thing...) but some are much faster than others. Command line ones can be pretty slick. Still, it comes down to team (and individual) preference and experience (your "very hard"s are never even "hard" in my experience). Even on a personal project that's going to span a decent length of time, I'll take the slowness of adding even a minor issue and the rare risk of grooming/popping the backlog (and all this might just be in a single local text file, very low overhead) only to discover an item no longer applies and taking the second to Never it. It's not only faster for me in the long run but maximizes the incentives for the things I want in a system that I'm tasked with maintaining and improving.
- edflsafoiewq 7y ago
  Coupling it to the code that it affects is nice. If the commit never makes it into master a TODO doesn't either. If the function it's in gets rewritten, the TODO goes away. etc.
- wutbrodo 7y ago
  I don't see why you'd hobble yourself by removing a method of tracking todos, in favor of one that's higher-overhead and more dangerous (much higher chance of getting out of date due to implicit coupling). > If it's not worth of the issue tracker, it shouldn't be worth of a TODO either. This is what I mean by throwing away work. If you have some insight about the code, your requirement that the insight be thrown away until you can "prioritize, track, and categorize it" makes no sense. Allowing a lighter-weight annotation that lives with the code that it describes allows much more flexibility: it's descriptive of the code and agnostic to its eventual fit into your tasking, as you can integrate it into formally tracked tasks or lump it in with related changes. Blanket bureaucratic rules for bureaucracy's sake is pointless, and I say that as someone who's a very strong believer in ticket tracking hygiene.

sedatk 7y ago

You don't throw it away, you put it in the issue tracker where it can be prioritized, tracked and categorized. If it's not worth of the issue tracker, it shouldn't be worth of a TODO either.

danShumway 7y ago
Eh. This is a company culture thing that depends on how you use your tracker. At many companies, issue trackers are not used for things like "refactor this method". They're used for user-facing stories or architectural projects, and they're transparent to managers who don't want them cluttered with non-user facing stories. I've run into managers who didn't want any TODOs in code, they wanted everything to go through the tracker. I've also run into managers that told me to stop putting everything into the tracker because they didn't know how to prioritize a random method refactor, and they felt like that information wasn't relevant to their scheduling. I don't have a strong preference, but I lightly lean towards preferring the latter strategy. Issue trackers are slow. They are so slow, and so cumbersome, and so hard to organize, and you waste so much time linking to code files that get refactored or moved around so the context is lost. The nice thing about a TODO in code is if the method gets deleted, the TODO also gets deleted. When you're refactoring code, you don't have to go search an issue tracker and think, "wait, is there anything related to this refactor I need to update?" If documentation is code that never gets compiled, issue trackers are like dynamically linked libraries that never actually get compiled or linked. It's very hard to keep them up-to-date; it's very hard to preserve the references. For smaller, single-person independent projects, I don't use issue trackers. I use high-level todo lists, and all of my notes are in code next to the context they're being used for. This is because an issue tracker is just bloat for those kinds of projects.
- Jach 7y ago
  I think it's less of a company culture thing and more of a local team preference thing. If the ICs on a team are united, managers are often willing to change things a bit from how they're used to it. It could be just as simple as prefixing a "[Trust]" tag to items that are important and have some priority within developer minds, but product management has no opinion / ability to form an opinion apart from earlier they've agreed on a general "[Trust]" bucket to account for such things. This lets them be filtered out as needed. Worst case, a united team can have a private issue tracker and beef up their estimates to management to account for work management doesn't want to hear about but needs doing nonetheless. If you don't have either a united team or managers willing to move at all, or even work with ICs collaboratively, you have bigger problems than what you do with TODO et al. If I were in such a situation I'd still use an 'issue tracker' (maybe a local text file) 9 times out of 10, while also looking for a better job. Issue trackers are slow and I have to work with one of the slowest (it was built in-house on top of a core product never meant for such a thing...) but some are much faster than others. Command line ones can be pretty slick. Still, it comes down to team (and individual) preference and experience (your "very hard"s are never even "hard" in my experience). Even on a personal project that's going to span a decent length of time, I'll take the slowness of adding even a minor issue and the rare risk of grooming/popping the backlog (and all this might just be in a single local text file, very low overhead) only to discover an item no longer applies and taking the second to Never it. It's not only faster for me in the long run but maximizes the incentives for the things I want in a system that I'm tasked with maintaining and improving.
edflsafoiewq 7y ago
Coupling it to the code that it affects is nice. If the commit never makes it into master a TODO doesn't either. If the function it's in gets rewritten, the TODO goes away. etc.
wutbrodo 7y ago
I don't see why you'd hobble yourself by removing a method of tracking todos, in favor of one that's higher-overhead and more dangerous (much higher chance of getting out of date due to implicit coupling). > If it's not worth of the issue tracker, it shouldn't be worth of a TODO either. This is what I mean by throwing away work. If you have some insight about the code, your requirement that the insight be thrown away until you can "prioritize, track, and categorize it" makes no sense. Allowing a lighter-weight annotation that lives with the code that it describes allows much more flexibility: it's descriptive of the code and agnostic to its eventual fit into your tasking, as you can integrate it into formally tracked tasks or lump it in with related changes. Blanket bureaucratic rules for bureaucracy's sake is pointless, and I say that as someone who's a very strong believer in ticket tracking hygiene.