6 ms·

Tracking in external system adds overhead not only for filing the issue, but also for triaging it, backlog management, re-triaging to see if it's still a proble

by pornel 1y ago

Tracking in external system adds overhead not only for filing the issue, but also for triaging it, backlog management, re-triaging to see if it's still a problem, and then closing it when it's finished. Issues in an external systems may also be overlooked by developers working on this particular code. There are plenty of small things that are worth fixing, but not worth as much as the overhead of tracking them. TODO in code is easy to spot when someone is working on this code, and easy to delete when the code is refactored.

OrderlyTiamat 1y ago
You can leave the TODO in the comments- e.g. ruff the linter has an optional rule to disallow TODO comments unless it's followed by an issue url. If you put that in the CI, then you can use TODOs either as blockers you wish to fix before merging, or as long term comments to be fixed in a future ticket.
- evnu 1y ago
  Some years ago, I started to use FIXME to indicate that something is blocking the PR and needs to be done before merging, and TODO if something can be done at a later point in time. Then, CI only needs to grep for FIXME to block merging the PR, which works for practically any language. Works pretty well for me, maybe that tip can help others as well.
pc86 1y ago
> Tracking in external system adds overhead not only for filing the issue, but also for triaging it, backlog management, re-triaging to see if it's still a problem, and then closing it when it's finished. Which is already what you're doing in that system, and what the system is designed for. Source code is not designed to track and management issues and make sure they get prioritized, so you shouldn't be using your source code to do this. We add TODOs during development, and then during review we either add a ticket and remove the TODO, or fix the issue as part of the PR and remove the TODO.
- motorest 1y ago
  > Source code is not designed to track and management issues and make sure they get prioritized, so you shouldn't be using your source code to do this. Indeed. Who in their right mind would think it is reasonable to track relevant tasks purposely outside of a system designed and used explicitly to get tasks done? Also, no one prevents a developer from closing a ticket before triaging it. If you fix a TODO, just post a comment and close it. I mean, will your manager complain about effortlessly clearing the backlog? Come on.
- lmm 1y ago
  > Which is already what you're doing in that system, and what the system is designed for. No it isn't. The system is designed to get managers to pay for it and it does that very well, it's very ineffective at tracking or triaging issues. > Source code is not designed to track and management issues and make sure they get prioritized, so you shouldn't be using your source code to do this. Most things that people build systems for managing outside of the source code repo end up being less effective to manage that way.
  - pc86 1y ago
    This is just intellectually lazy IMO. "Ticket management software isn't good at managing tickets, it's just good at getting stupid CTOs to pay for it because execs are stupid didn't you guys know?" I'm sure that's true for enterprise bloatware, but there are dozens of excellent open source and/or low cost issue trackers. Hell, Trello will do about 90% of what you need out of the box if you're operating with 1-3 people.
    - aaronbaugher 1y ago
      The main problem I have with ticketing (and project management) systems is that I can't get the people asking me to do things to use the system. I'll set it up and show them how to use it, and then they tell me about issues via email or text message or voice call. I end up entering the tickets/tasks myself, at which point I might as well be using my own org-mode setup.
LeifCarrotson 1y ago
I think the key distinction is that tracking in an external system exposes the task for triage/management/prioritization to people who aren't reading the code, while a TODO comment often leaves the message in exactly the spot where a programmer would read it if the possibility of a problem became an actual problem that they had to debug. In my experience, these can often be replaced with logger.Error("the todo") or throw new Exception("the todo"), which read about as well as //TODO: the todo, but also can bubble up to people not actually reading the code. Sometimes, though, there's no simple test to trigger that line of code, and it just needs to be a comment.
- WorldMaker 1y ago
  I've also seen good use of automation tools that monitor the codebase for TODOs and if they last for more than a couple weeks escalate them into a "real" ticketing system. (I've also seen that backfire and used to punish engineering.) SonarQube, for instance, will flag TODOs as "Code Smells" and then has some automation capabilities to eventually escalate those to tickets in certain systems if plugins are configured. I've also seen people do simpler things with GitHub Actions to auto-create GitHub Issues.
  - alchemyzach 1y ago
    > I've also seen good use of automation tools that monitor the codebase for TODOs and if they last for more than a couple weeks escalate them into a "real" ticketing system Im sorry but that’s exactly the kind of automation that sounds helpful in theory but ends up creating bloat and inefficiency in practice. Like the article says, the second a TODO gets a timer/deadline attached, it stops being a quick, lightweight note and turns into process overhead (note the distinction between something that is urgent and needs fixing now, and something that really is just a TODO). Maybe a weird way to put it, but it’s like a TODO that used to be lean and trail-ready - able to carry itself for miles over tough terrain with just some snacks and water - suddenly steps on a scale and gets labeled “overweight" and "bloated" and flagged as a problem, and sent into the healthcare system. It loses its agility and becomes a burden. "But the TODO is a serious problem that does need to get addressed now" Ok then it was never actually a TODO, and thats something to take up with the dev who wrote it. But most TODOs are actually just TODOs - not broken code, but helpful crumbs left by diligent, benevolent devs. And if you start to attack/accuse every TODO as "undone work that needed to be done yesterday" then youll just create a culture where devs are afraid to write them, which is really stupid and will just create even more inefficiency/pitfalls down the road - way more than if you had just accepted TODOs as natural occurrences in codebases
motorest 1y ago
> Tracking in external system adds overhead not only for filing the issue, but also for triaging it, backlog management, re-triaging to see if it's still a problem, and then closing it when it's finished. Filing the issue can take as long as writing the TODO message. Triaging it, backlog management, re-triaging to see if it's still a problem... It's called working on the issue. I mean, do you plan on working on a TODO without knowing if it is still a problem? Come on. > Issues in an external systems may also be overlooked by developers working on this particular code. I stumbled upon TODO entries that were over a decade old. TODOs in the code are designed to be overlooked. The external system was adopted and was purposely designed to help developers track issues, including bugs. You are also somehow assuming that there is no overhead in committing TODO messages. I mean, you need to post and review a PR to update a TODO message? How nuts is that. > There are plenty of small things that are worth fixing, but not worth as much as the overhead of tracking them. If those small things are worth fixing, they are worth filing a ticket. If something you perceive as an issue is not worth the trouble of tracking, it's also not worth creating a comment to track it.
RandallBrown 1y ago
This gives me an idea for a source control/task task tracking system where TODOs in code get automatically turned into tickets in your tracker, and then removed from your code automatically. That way you don't fill your code with a list of TODOs and you'll still be able to track what you want to improve in your codebase. It might not be the right tool for everyone, but I'd love it.
- mystifyingpoi 1y ago
  Check out Puzzle Driven Development.
- CRConrad 1y ago
  > TODOs in code get automatically turned into tickets in your tracker, and then removed from your code automatically. Better yet (IMO), not removed but replaced by a ticket number or link to the issue.
alchemyzach 1y ago
> There are plenty of small things that are worth fixing, but not worth as much as the overhead of tracking them THANK YOU

by pornel 1y ago

OrderlyTiamat 1y ago

You can leave the TODO in the comments- e.g. ruff the linter has an optional rule to disallow TODO comments unless it's followed by an issue url. If you put that in the CI, then you can use TODOs either as blockers you wish to fix before merging, or as long term comments to be fixed in a future ticket.

evnu 1y ago
Some years ago, I started to use FIXME to indicate that something is blocking the PR and needs to be done before merging, and TODO if something can be done at a later point in time. Then, CI only needs to grep for FIXME to block merging the PR, which works for practically any language. Works pretty well for me, maybe that tip can help others as well.

pc86 1y ago

> Tracking in external system adds overhead not only for filing the issue, but also for triaging it, backlog management, re-triaging to see if it's still a problem, and then closing it when it's finished. Which is already what you're doing in that system, and what the system is designed for. Source code is not designed to track and management issues and make sure they get prioritized, so you shouldn't be using your source code to do this. We add TODOs during development, and then during review we either add a ticket and remove the TODO, or fix the issue as part of the PR and remove the TODO.

motorest 1y ago
> Source code is not designed to track and management issues and make sure they get prioritized, so you shouldn't be using your source code to do this. Indeed. Who in their right mind would think it is reasonable to track relevant tasks purposely outside of a system designed and used explicitly to get tasks done? Also, no one prevents a developer from closing a ticket before triaging it. If you fix a TODO, just post a comment and close it. I mean, will your manager complain about effortlessly clearing the backlog? Come on.
lmm 1y ago
> Which is already what you're doing in that system, and what the system is designed for. No it isn't. The system is designed to get managers to pay for it and it does that very well, it's very ineffective at tracking or triaging issues. > Source code is not designed to track and management issues and make sure they get prioritized, so you shouldn't be using your source code to do this. Most things that people build systems for managing outside of the source code repo end up being less effective to manage that way.
- pc86 1y ago
  This is just intellectually lazy IMO. "Ticket management software isn't good at managing tickets, it's just good at getting stupid CTOs to pay for it because execs are stupid didn't you guys know?" I'm sure that's true for enterprise bloatware, but there are dozens of excellent open source and/or low cost issue trackers. Hell, Trello will do about 90% of what you need out of the box if you're operating with 1-3 people.
  - aaronbaugher 1y ago
    The main problem I have with ticketing (and project management) systems is that I can't get the people asking me to do things to use the system. I'll set it up and show them how to use it, and then they tell me about issues via email or text message or voice call. I end up entering the tickets/tasks myself, at which point I might as well be using my own org-mode setup.

LeifCarrotson 1y ago

I think the key distinction is that tracking in an external system exposes the task for triage/management/prioritization to people who aren't reading the code, while a TODO comment often leaves the message in exactly the spot where a programmer would read it if the possibility of a problem became an actual problem that they had to debug. In my experience, these can often be replaced with logger.Error("the todo") or throw new Exception("the todo"), which read about as well as //TODO: the todo, but also can bubble up to people not actually reading the code. Sometimes, though, there's no simple test to trigger that line of code, and it just needs to be a comment.

WorldMaker 1y ago
I've also seen good use of automation tools that monitor the codebase for TODOs and if they last for more than a couple weeks escalate them into a "real" ticketing system. (I've also seen that backfire and used to punish engineering.) SonarQube, for instance, will flag TODOs as "Code Smells" and then has some automation capabilities to eventually escalate those to tickets in certain systems if plugins are configured. I've also seen people do simpler things with GitHub Actions to auto-create GitHub Issues.
- alchemyzach 1y ago
  > I've also seen good use of automation tools that monitor the codebase for TODOs and if they last for more than a couple weeks escalate them into a "real" ticketing system Im sorry but that’s exactly the kind of automation that sounds helpful in theory but ends up creating bloat and inefficiency in practice. Like the article says, the second a TODO gets a timer/deadline attached, it stops being a quick, lightweight note and turns into process overhead (note the distinction between something that is urgent and needs fixing now, and something that really is just a TODO). Maybe a weird way to put it, but it’s like a TODO that used to be lean and trail-ready - able to carry itself for miles over tough terrain with just some snacks and water - suddenly steps on a scale and gets labeled “overweight" and "bloated" and flagged as a problem, and sent into the healthcare system. It loses its agility and becomes a burden. "But the TODO is a serious problem that does need to get addressed now" Ok then it was never actually a TODO, and thats something to take up with the dev who wrote it. But most TODOs are actually just TODOs - not broken code, but helpful crumbs left by diligent, benevolent devs. And if you start to attack/accuse every TODO as "undone work that needed to be done yesterday" then youll just create a culture where devs are afraid to write them, which is really stupid and will just create even more inefficiency/pitfalls down the road - way more than if you had just accepted TODOs as natural occurrences in codebases

motorest 1y ago

> Tracking in external system adds overhead not only for filing the issue, but also for triaging it, backlog management, re-triaging to see if it's still a problem, and then closing it when it's finished. Filing the issue can take as long as writing the TODO message. Triaging it, backlog management, re-triaging to see if it's still a problem... It's called working on the issue. I mean, do you plan on working on a TODO without knowing if it is still a problem? Come on. > Issues in an external systems may also be overlooked by developers working on this particular code. I stumbled upon TODO entries that were over a decade old. TODOs in the code are designed to be overlooked. The external system was adopted and was purposely designed to help developers track issues, including bugs. You are also somehow assuming that there is no overhead in committing TODO messages. I mean, you need to post and review a PR to update a TODO message? How nuts is that. > There are plenty of small things that are worth fixing, but not worth as much as the overhead of tracking them. If those small things are worth fixing, they are worth filing a ticket. If something you perceive as an issue is not worth the trouble of tracking, it's also not worth creating a comment to track it.

RandallBrown 1y ago

This gives me an idea for a source control/task task tracking system where TODOs in code get automatically turned into tickets in your tracker, and then removed from your code automatically. That way you don't fill your code with a list of TODOs and you'll still be able to track what you want to improve in your codebase. It might not be the right tool for everyone, but I'd love it.

mystifyingpoi 1y ago
Check out Puzzle Driven Development.
CRConrad 1y ago
> TODOs in code get automatically turned into tickets in your tracker, and then removed from your code automatically. Better yet (IMO), not removed but replaced by a ticket number or link to the issue.

alchemyzach 1y ago

> There are plenty of small things that are worth fixing, but not worth as much as the overhead of tracking them THANK YOU