4 ms·

I agree with the OP - you have immediately lost the linkage between the lines of code and the problem description - maybe you put a reference to the lines / mo

I agree with the OP - you have immediately lost the linkage between the lines of code and the problem description - maybe you put a reference to the lines / modeule in the ticket but really, why bother. You could do "TODO fix the foobar because flange see Ticket 1234" (and I have a todoinator to automate that but I think a ticket should be more meaty than a todo but perhaps I am fooling myself

monkpit 4y ago
You’re absolutely fooling yourself - a ticket is a unit of work. Trying to hide tech debt by keeping it out of the project management system is not beneficial.
- lifeisstillgood 4y ago
  The code base is the project management system - the dialogue between developers is the way code is developed - and the project management system is a pale copy of the real system used to keep non-literate people happy and feel they have some input. Progress is measured by working software not closed tickets.
- sdiupIGPWEfh 4y ago
  No one's trying to hide anything. The target users of project management systems, product owners and anyone with with a project manager title, typically neither care about nor understand the value of rework. In their view, the dev teams should be creating maximum value at all times, which they understand as either adding features or putting out fires. Rework tickets do not get prioritized until they're identified as the cause of lost value. The inevitable question is "well why wasn't it written correctly to begin with?" even if the reason, as is typical, was pressure from product managers in the first place.
simplotek 4y ago
> 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.

monkpit 4y ago

You’re absolutely fooling yourself - a ticket is a unit of work. Trying to hide tech debt by keeping it out of the project management system is not beneficial.

lifeisstillgood 4y ago
The code base is the project management system - the dialogue between developers is the way code is developed - and the project management system is a pale copy of the real system used to keep non-literate people happy and feel they have some input. Progress is measured by working software not closed tickets.
sdiupIGPWEfh 4y ago
No one's trying to hide anything. The target users of project management systems, product owners and anyone with with a project manager title, typically neither care about nor understand the value of rework. In their view, the dev teams should be creating maximum value at all times, which they understand as either adding features or putting out fires. Rework tickets do not get prioritized until they're identified as the cause of lost value. The inevitable question is "well why wasn't it written correctly to begin with?" even if the reason, as is typical, was pressure from product managers in the first place.

simplotek 4y ago

> 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.