3 ms·
This is going to happen. The best way to handle this inevitable occurrence is to ticket this. The reviewer should ask for the ticket, and have the ticket linked
by jasonlotito 4y ago
This is going to happen. The best way to handle this inevitable occurrence is to ticket this. The reviewer should ask for the ticket, and have the ticket linked. The ticket should ready to go, and the author of the code should have it ready to go as the "next thing" to get done, whether that's the follow up, or it's getting picked up in the next sprint so it doesn't get missed.
The code reviewer should also watch that ticket, and be prepared to assist it pushing it through.
If you just leave the task in the code, it will get lost. And, on occasion, the pressure of needing to write a ticket will get someone to just make the fix instead of having to create the ticket.
- tsimionescu 4y agoMy experience is the precise opposite. Engineering tickets with no clear business value rot by the hundreds in sine corner of the backlog, at best being brought up occasionally as an "I told you so" when the business case does rear its head. In contrast, people working on the code for other reasons will notice a TO-DO and be much more likely to bring it up today, as some kind of "if I'm going to do changes in that area, I should also address this TODO, it will just take an extra $days". Or at least, it will guide them to the source of a long forgotten bug.
- sdiupIGPWEfh 4y agoMy experience matches yours, and I wanted to call that out with more than just an up-vote. The ticketing system is where rework goes to die. In an engineer-led environment without a project management class calling the shots, maybe I'd feel different, but whoever is ordering the backlog is always going to prioritize features and fires, because that's what drives their own career advancement.