I was just having this conversation with myself for another reason this morning (trying to define why automating processes is a force multiplier and mistake reducer). Because there’s little to no IDE integration for ticket tracking, swapping to the ticket system is a context switch. And the ticket system has ways of demanding your attention once you’re in there. If it succeeds now you’re pre-empted.

The thing about concurrency is that as long as you don’t know about a priority message you can continue to make progress on the task at hand. The moment you are aware of it you have to deal with it or have to explain yourself later. “I didn’t see it” goes a lot farther than, “I did but I was busy.”

My ex would try to check her work email on a Friday evening as we were on our way out the door for a trip out of town. A trip her boss likely knew about. That’s not why she’s my ex but it certainly didn’t help. That email arrived after you already left, lady. That’s your story and we are sticking to it. Don’t go looking for conflict, particularly when doing so affects people other than yourself.

I personally have no problem with the forcing function of a policy that makes you add a todo to a ticketing system.

It sets a bar for the todo to be at least more complex than creating a ticket. Any less and you can just do what the todo says to do.

Make the bar high enough and people won’t bother to do either and instead just hope for the best or keep their own list of TODOs elsewhere.

The point of a cheap informal method is to as low of a bar as possible so that more information is collected. As for always immediately fixing that’s the same as making everything the top priority, the true priority is lost.

Too many TODO comments and not enough tracked issues, that’s a sign that issue tracking has too much ceremony. Ban the use of TODOs and you lose even that information.

Perhaps a codebase could be watched such that new tracking issues are added and tracked implicitly when checked in by searching for new TODOs in the code. Similarly the tracking issue could be closed when the corresponding TODO is deleted from the code.

As Hinkley says, it's a task switch cost. Tickets may also involve a whole load more circus. They get seen by managers with metrics. The advantage of an in-place TODO is precisely that it doesn't get seen by people to whom it is not relevant, and that it can be left indefinitely.

Notably, if that TODO is turned into a ticket, there's a good chance it'll get triaged and eventually marked as cancelled/wontfix. Which is a perfectly reasonable thing to do when part of backlog management is saying no to things that'll never get prioritised. But, that work is still sitting there not done, and capturing that _somewhere_ has value, and alongside the code is about as context-rich as you can hope for.

If it takes more than 20 seconds to make a ticket, that’s your real problem.

I have often problems with these 20 seconds tickets. I takes another 20 minutes to call the author and ask what he meant by writing these few meaningless words and what’s exactly is the issue. Then add useful description to the ticket and look who is the responsible developer for the part. So no, 20 second tickets are problems and time waste, not the solutions.