I want to believe it means one day we will do that TODO, it'll beat the priority of all the other tickets in the queue.
But it never does, there's always some critical new feature sales wants, or something bigger on fire.
I still create the tickets, as a kind of cathartic process, a confession to the jira gods, I have sinned and half assed something. Please take this ticket as my penance.
Then clearly it is not deserving of your attention according to the powers that be. If it is, then talk in the language that these parties understand better/prefer: bump up the priority of the task, add a "blocked by" or "has to be done after" link to these other issues in the tracker and tell the rest of the teammates that you'll be working on that piece of technical debt instead of the new feature.
If you can't do that, then either the "TODO" comments/issues aren't important enough, or they're not deemed to be and will/should simply be left to rot until you either have an abundance of time to address them (which may be never), or the project is retired.
If more pushback is necessary, then do it doing any estimates (provided that you have any): "Task $FOO will take X% more time due to $BAR not being finished and slowing down development. Consider doing $BAR first and $FOO should become less complex then."
In those cases, there's a way to keep management happy and yourself too:
1) Realize that when management asks for time estimates, they don't want your median estimate, because you'll be late half the time and that messes up their scheduling. Give them an estimate that you'll meet at least 90% of the time.
2) This means in almost half the cases, you'll have extra time. You can give some of that back to management, but use some of the time to fix technical debt. The more debt, the more of the time you spend fixing it.
3) With less technical debt, you can speed up your estimates and still be at that 90% level. Now you're delivering as much as if you let management fill your time in the first place. Your code magically has fewer bugs, there aren't many unexpected delays, and you almost always meet your deadlines. But you still have plenty of free time to improve things even more, develop your skills, etc.
As a bonus, you have more of a sense of agency, which is an important factor in feeling happy at work.
Creating those estimates alone is more than the sum of total work usually.
Then the problem of convincing others is itself typically more than the sum of total work.
Usually metrics aren't accurate enough to be able to prove these things anyway in my experience.
task systems are frequently awful at team-owned (not necessarily an individual) lightweight checks.
If that was true then it would be trivial to just push a pull request and update the ticket to review it.
> Then the problem of convincing others is itself typically more than the sum of total work.
When that happens, that's the universe trying to explain to you that you're wasting your time with stuff that does not add tangible value.
This does not change with petty office politics moves such as ignoring your team's best judgement and continue pushing for something that was already decided to be a waste of time.
Then simply add those hours spent estimating things to whatever time management solution that you use personally (for insights into where your time goes each quarter/year) or that your company mandates (for basically the same thing). If it's an actual problem, then simply raise it as such later down the road and look for ways to streamline things.
Most of the time you shouldn't care about how much time something takes (exceptions exist, based on the industry/project, but many deadlines are made up anyways), merely that the time to be spent on the task has been approved and that you're not doing something that isn't documented/categorized, e.g. time that "disappears" by being spent on things that don't have any sort of visibility/basis for taking up your time.
If changing how a button works takes 2 hours but writing tests takes 4 and refactoring old code takes another hour, then let the record show exactly that. If unclear requirements cause you to spend another hour or two in meetings and talking to people who didn't document code or explain their changes in merge/pull requests, then let the record show that, too.
Of course, this might vary on a per-company/project/culture basis.
> Then the problem of convincing others is itself typically more than the sum of total work.
If others in the team don't want to fix these things, then they probably aren't as important/annoying as you think they are and therefore probably won't be prioritized so highly anyways. When there are really annoying/brittle API integrations, for example, most devs usually should back you up in your efforts in making things less horrible.
> Usually metrics aren't accurate enough to be able to prove these things anyway in my experience.
You don't actually need metrics that are completely accurate, because finding ones that are is seldom easy to do or even possible, or simply not worth the effort. Having something to the tune of "This API integration can be improved, the last 3 feature requests related to it exceeded their estimates by quite a bit" should be enough, provided that you can get the other people on board.
If you cannot, then it's probably an issue of the actual work environment/culture and/or soft skills.
> But it never does, there's always some critical new feature sales wants, or something bigger on fire.
Why do you expect that random comments in the code will affect the priority of some tasks? Do you feel that stashing out-of-band info on pending tasks which were deemed not important regarding the project workload changes anything?
Also, if everything is always more important than the TODO item, that is the universe telling you that your TODO item should be deleted and that you should stop wasting your bandwidth with useless and unnecessary tasks.
It really isn't.
A TODO item that you feel does not justify a ticket is just a subjective nice-to-have expressed as noise/a declaration of intent with no intention to deliver, which ultimately only results in noise.
It's not even technical debt. At most, it's a pledge to goldplate something without being able to argue any tangible upside.
> A few bytes is nothing compared to Management's roadmap, so it gets ignored.
Bytes are irrelevant. Tickets also cost bytes. Tickets also track rationale and context. What really matters is allocated resources in order to deliver value.
The only reason your TODO item gets ignored is because the potential value it promises does not justify allocating resources to it.
People need to be smart about how they invest their time and effort. Tracking vague tasks deemed unnecessary or useless in a separate out-of-band source of info is not productive and ends up only creating noise and distractions.
