G
Show HN
Show HN: DebtBomb – Make TODOs expire and automatically create Jira tickets
Hi HN, In most codebases I’ve worked on, temporary hacks (“TODO: remove later”, “just for this release”) slowly become permanent. Nobody remembers why they exist, but they keep shipping to production. I built a small CLI called DebtBomb to make that explicit. Instead of free-form TODOs, you attach an expiry date to temporary code. When the date passes, CI fails until the code is removed or the expiry is intentionally extended. Recently I added integrations so expired debt bombs don’t just fail CI — they become visible and owned: When a debt bomb expires, DebtBomb can automatically create a Jira ticket with file path, owner, reason, and code snippet. It can also notify Slack, Discord, or Microsoft Teams. You can configure “expiring soon” warnings (e.g., 7 days before) so it’s not just a surprise break. Repo: https://github.com/jobin-404/debtbomb This is still early and I’m mainly trying to validate whether this actually improves how teams handle “temporary” code compared to TODOs, linters, or just creating tickets manually. I’d especially love feedback from people who’ve dealt with tech debt in long-lived codebases or CI-heavy environments. Thanks for reading.
I've seen something like this tried before. What ended up happening was that not all TODOs were handled in a short period of time, some of them expired, then everyone was cross the build failed and the offending TODO was promptly given an extension.

Maintaining code quality and TODOs turns out to be a surprisingly hard problem, but it's far more of a social / organisational one than technical, which is why technical tools don't solve it.

There's a much higher-ROI way to encode these, write a test that checks the current date. Maybe a very large project would prefer not to fail everyone's build for it, but this is fine for a couple dozen developers.

Example: https://github.com/lobsters/lobsters/commit/9e99fbf1d3cc441e...

Not all TODOs are bad though, they may be a temporary turned permanent implementation that may be just as fine but the author may have wanted to do it properly or a bit nicer but which will never happen.
Totally agree. Many TODOs are just “this could be nicer someday.” DebtBomb is only for cases that are intentionally temporary.
I always advocate that TODO comments include a link to a ticket tracking the TODO during code review.

It’s easy to get a team to make this 2nd nature and gets immediate debt in the backlog. It can of course still be ignored and unfinished for a long time still but no amount of automated nagging will change that in my experience

I am personally not a fan of TODOs, use tasks instead. TODOs are embedded in codebase - difficult to work with, that's why we have Jira where you can manipulate, filter and aggregate tasks. The only acceptable case of TODOs in my opinion is to leave them as suggestions to a future person in the case of refactor. Then you could have a task that says something like "Refactor feature xyz and solve TODOs".
  • 9dev
  • ·
  • 1 hour ago
  • ·
  • [ - ]
The way I use them, is for annotating possible extension points or refinements that would improve things, but are more of the "nice to have" kind, or stuff someone coming across might want to take care of later. Many of these don’t warrant real issues in a tracker, as they would just clog the backlog and get eventually deleted anyway.
The codebase is only hard to work with in the ways it's meant to be - they are very easy to find with `git grep` and they are right next to the code in question so are easy to see when you're working on it. Conversely, they are hard to just 'lose' when some PM decides to have a "JIRA cleanup", which is also by design.
Might wanna add a snooze feature. We use this in code security, as a break-glass scenario
Expiring TODOs automatically is a dumb idea, about as dumb as closing unresolved issues automatically. TODOs in the code serve as documentation of the limitations of a feature, close to where a developer needs them. As such it's best to keep TODOs in the code, with an issue tracker serving only as a mirror, not a substitute.
The idea isn’t to auto-close or hide anything, but to stop those time-bound decisions from silently becoming permanent
I think it's a great idea.

In my experience this kind of thing works only with the discipline and will to actually get to it, and that really depends on the project, team and management dynamic.

I've been receiving a "stale issue, closing soon" notification on an open source project every two months for over a year, which I dutifully bump and the issue continues to be studiously ignored. Much respect to that team, but the techno-fix of quarterly reminders are not addressing the core issue of missing will, process or personnel. It's a bit like setting a clock ahead in order to leave on time: the will to be on time is the driver, not the clock.

However, for those teams with the will and process to address old TODOs, seems like a nice reminder. I might use it!

oh hell nah
Ahh from one dark corner to another; filling up the jira backlog