5 ms·

> You could do "TODO fix the foobar because flange see Ticket 1234" No, you should create Ticket 1235 - fix foobar, add additional info such as rationale and t

> You could do "TODO fix the foobar because flange see Ticket 1234" No, you should create Ticket 1235 - fix foobar, add additional info such as rationale and the definition of done, and add Ticket 1234 as related/blocks.

convolvatron 4y ago
how am I going to know there is such a ticket when I'm looking at the code?
- lifeisstillgood 4y ago
  Xcellent point - and we need ways to sync the two but based in code. I am tempted to try and build something that uses module and line number and bags of the comment to build a unique reference for the ticket to point back to - but I wonder about code movement and have never done it
  - convolvatron 4y ago
    personally I think the right answer is to finally lose the idea of code-as-text and build structures with all kinds of optional metadata.
wtetzner 4y ago
And that ticket will be forever ignored. On the other hand, if there’s a TODO in the code, someone might fix it the next time they’re editing that part of the code.
- monkpit 4y ago
  Your team should be grooming and prioritizing the backlog. If the tech debt exists but the business doesn’t value working on it, then yes it won’t get worked. But it also wouldn’t ever get done as some stray //TODO either.
  - lifeisstillgood 4y ago
    Then don't make it "stray" - parse the code for todos and other lintable items - and yes some grooming is needed - but don't make the ticketing system drive the development- that's the tail wagging the dog, or looking at the receipt at the restaurant and thinking that's what caused the chef to cook the meal.
  - sdiupIGPWEfh 4y ago
    Unless you're in a Scrum team and "The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering." is taken to mean that the PO has the final say on what's prioritized. If your PO has a project manager title, as most do, and they see their career advancement is tied to shipping features on or ahead of schedule, then indeed, that ticket will be forever ignored.
- lifeisstillgood 4y ago
  Thank you .. exactly A team that spends all its time grooming the backlog is not spending time on reading code, logs inputs, output, data etc. We have fooled ourselves into thinking ticketing systems represent living documents but they don't - a high functioning team can have "hey I will fix the foobar by adding a cromulent adjutant" in a office (!) call or even an email. A low functioning team knows no one will get round to fixing it

convolvatron 4y ago

how am I going to know there is such a ticket when I'm looking at the code?

lifeisstillgood 4y ago
Xcellent point - and we need ways to sync the two but based in code. I am tempted to try and build something that uses module and line number and bags of the comment to build a unique reference for the ticket to point back to - but I wonder about code movement and have never done it
- convolvatron 4y ago
  personally I think the right answer is to finally lose the idea of code-as-text and build structures with all kinds of optional metadata.

wtetzner 4y ago

And that ticket will be forever ignored. On the other hand, if there’s a TODO in the code, someone might fix it the next time they’re editing that part of the code.

monkpit 4y ago
Your team should be grooming and prioritizing the backlog. If the tech debt exists but the business doesn’t value working on it, then yes it won’t get worked. But it also wouldn’t ever get done as some stray //TODO either.
- lifeisstillgood 4y ago
  Then don't make it "stray" - parse the code for todos and other lintable items - and yes some grooming is needed - but don't make the ticketing system drive the development- that's the tail wagging the dog, or looking at the receipt at the restaurant and thinking that's what caused the chef to cook the meal.
- sdiupIGPWEfh 4y ago
  Unless you're in a Scrum team and "The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering." is taken to mean that the PO has the final say on what's prioritized. If your PO has a project manager title, as most do, and they see their career advancement is tied to shipping features on or ahead of schedule, then indeed, that ticket will be forever ignored.
lifeisstillgood 4y ago
Thank you .. exactly A team that spends all its time grooming the backlog is not spending time on reading code, logs inputs, output, data etc. We have fooled ourselves into thinking ticketing systems represent living documents but they don't - a high functioning team can have "hey I will fix the foobar by adding a cromulent adjutant" in a office (!) call or even an email. A low functioning team knows no one will get round to fixing it