4 ms·

I've already built a little tooling around pull requests and git commits at autodesk and so when I read this, I thought, oh, yeah, that's a great idea, I should

I've already built a little tooling around pull requests and git commits at autodesk and so when I read this, I thought, oh, yeah, that's a great idea, I should do that. But here's the thing. Our team already has a policy for TODOs: either you open a ticket and leave the ticket number in the code, or you do not leave a todo at all. This way, we're never guessing which ticket belong to which todo, and all of the necessary context (including what spawned the todo, why it may or may not have been a good idea, etc) can be present with the code. I think in this case, the policy is a better system than just randomly opening tickets. It increases the barrier to entry if you are going to leave a TODO (versus leaving it out or just not being lazy and doing it), and prevents the backlog from needing even more grooming.

gravypod 7y ago
> It increases the barrier to entry if you are going to leave a TODO (versus leaving it out or just not being lazy and doing it), and prevents the backlog from needing even more grooming I would rather have many tickets that specify actual work than a lot of work specified in no tickets. Using monotony as a filter doesn't sound like it would lower defect rates over long periods of time.
- MAGZine 7y ago
  Conversely, it actually serves as a reminder for you to prioritize the work rather than coming across and old todo as a happenchance, when you're not in the frame of mind or have the time to fix it. Yes, it's tedium. But it's necessary tedium. It's documentation.