4 ms·

> Actively keeping a backlog is most often simply a waste of time. That is not only the case for feature tasks but also for bug reports – a bug that has not bee

by berkes 6y ago

> Actively keeping a backlog is most often simply a waste of time. That is not only the case for feature tasks but also for bug reports – a bug that has not been addressed for the past six months is unlikely to be addressed in the coming six months. This makes me uncomfortable. I don't exactly know why, but the thought that ideas, nice-to-haves, and bugs move to a /dev/null of some sort, does not resonate with me. What if that bug re-appears after 7 months. You'd want to pull up the old one and go: "see, it still hardly ever happens, but here's another one". You could rename the backlog to "archive", but that hardly makes it different: a backlog is still a list of stuff you had no time to think about.

marcoow 6y ago
Not maintaining a backlog doesn't necessarily mean you cannot collect ideas etc. anywhere. I think the two main points are: * putting effort into preparing proper tickets for all these ideas is likely wasted time as 90% of the ideas will never be taken on * keeping all the ideas together with the issues that are actually important creates noise and makes it harder to identify the actually important stuff; also having a backlog with thousands of open tickets puts loads of emotional pressure on teams since they are always feeling like they lack behind while in reality most of those thousands of tickets are irrelevant anyway. Also I'm not sure what the point of being able to say > "see, it still hardly ever happens, but here's another one". would be really (except for being right about the existence of something) – if the decision is not to fix the bug it's irrelevant still.
- maaarghk 6y ago
  https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/#:~:text=5.%20Do%20you https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...
  - marcoow 6y ago
    Sure, you should have bugs documented somewhere but I'm not sure a bug that hasn't been fixed for x months needs to be there since it's a bug the team obviously decided not to care about.
    - watwut 6y ago
      I personally fixed bugs that have been opened for longer then that, so nope, they can get fixed. Plus, it prevents people from opening them again and again and again and again as they all notice the same thing.
      - cpeterso 6y ago
        I've fixed a couple Firefox bugs that were filed in Bugzilla 10-15 years ago. :) At least one fix, however, upset some people who come to like the "incorrect" behavior over those 10-15 years. (In one case, I changed the filename of saved web pages from "index.html" to HTML <title> .html to match Chrome and IE behavior.) This xkcd comic is relevant: https://xkcd.com/1172/ https://xkcd.com/1172/
  - commandlinefan 6y ago
    Reminds me of a recent Dilbert comic/quote: "Our boss can't judge the quality of our work, but he knows when it's late".
jasonpeacock 6y ago
ShapeUp[1] makes the same argument as TFA. Either it's a bug worth fixing now, or it's not. If it's not, ignore it. In reality, nobody ever goes through the backlog saying "gosh, I have nothing to do, let's find old bugs to fix". [1] https://basecamp.com/shapeup https://basecamp.com/shapeup
- danvasquez29 6y ago
  that's not true at all in my experience. In the past we've had "bug bash" type activities, or used that lower-hanging fruit as training opportunities. As an architect i've sometimes grabbed tasks like that just to stay fresh but also out of the way of the prioritized team backlog.
  - marcoow 6y ago
    Bug bashes are a bit like cool down periods in my experience – if your focus is 100% on features all of the time then every now and then you need to catch up on open bugs or piled up tech debt. I'd argue these types of activities are not necessary at all when all stakeholders contribute to the scope of each iteration (see https://simplabs.com/blog/2020/06/17/failing-and-winning-at-planning-software-projects#1-the-source-of-tasks https://simplabs.com/blog/2020/06/17/failing-and-winning-at-...). Still, if a bug isn't taken on for x weeks or months, I'd say 99% of the time it never will be and can just as well be closed since it's ignored anyway.
  - jasonpeacock 6y ago
    Yep, ShapeUp describes an open "Cool Down" period between cycles, where people are free to work on whatever they want - favorite bugs, features, docs, developer tools, etc. They discuss how everyone maintains their own personal list of what's important to them and use that to drive their work. But maintaining a single, centralized list of everything has little value. Anything important is already being tracked in the roadmap, including bugs impacting customers of sufficient priority. It really is worth reading the ShapeUp book, it provides a good, alternate view of commonly-held beliefs.
    - 6y ago
anitil 6y ago
That's what I've done with my email. It's either in my inbox, or 'archived'. Mentally much easier than deleting, but functionally the same

by berkes 6y ago

marcoow 6y ago

Not maintaining a backlog doesn't necessarily mean you cannot collect ideas etc. anywhere. I think the two main points are: * putting effort into preparing proper tickets for all these ideas is likely wasted time as 90% of the ideas will never be taken on * keeping all the ideas together with the issues that are actually important creates noise and makes it harder to identify the actually important stuff; also having a backlog with thousands of open tickets puts loads of emotional pressure on teams since they are always feeling like they lack behind while in reality most of those thousands of tickets are irrelevant anyway. Also I'm not sure what the point of being able to say > "see, it still hardly ever happens, but here's another one". would be really (except for being right about the existence of something) – if the decision is not to fix the bug it's irrelevant still.

maaarghk 6y ago
https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/#:~:text=5.%20Do%20you https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...
- marcoow 6y ago
  Sure, you should have bugs documented somewhere but I'm not sure a bug that hasn't been fixed for x months needs to be there since it's a bug the team obviously decided not to care about.
  - watwut 6y ago
    I personally fixed bugs that have been opened for longer then that, so nope, they can get fixed. Plus, it prevents people from opening them again and again and again and again as they all notice the same thing.
    - cpeterso 6y ago
      I've fixed a couple Firefox bugs that were filed in Bugzilla 10-15 years ago. :) At least one fix, however, upset some people who come to like the "incorrect" behavior over those 10-15 years. (In one case, I changed the filename of saved web pages from "index.html" to HTML <title> .html to match Chrome and IE behavior.) This xkcd comic is relevant: https://xkcd.com/1172/ https://xkcd.com/1172/
- commandlinefan 6y ago
  Reminds me of a recent Dilbert comic/quote: "Our boss can't judge the quality of our work, but he knows when it's late".

jasonpeacock 6y ago

ShapeUp[1] makes the same argument as TFA. Either it's a bug worth fixing now, or it's not. If it's not, ignore it. In reality, nobody ever goes through the backlog saying "gosh, I have nothing to do, let's find old bugs to fix". [1] https://basecamp.com/shapeup https://basecamp.com/shapeup

danvasquez29 6y ago
that's not true at all in my experience. In the past we've had "bug bash" type activities, or used that lower-hanging fruit as training opportunities. As an architect i've sometimes grabbed tasks like that just to stay fresh but also out of the way of the prioritized team backlog.
- marcoow 6y ago
  Bug bashes are a bit like cool down periods in my experience – if your focus is 100% on features all of the time then every now and then you need to catch up on open bugs or piled up tech debt. I'd argue these types of activities are not necessary at all when all stakeholders contribute to the scope of each iteration (see https://simplabs.com/blog/2020/06/17/failing-and-winning-at-planning-software-projects#1-the-source-of-tasks https://simplabs.com/blog/2020/06/17/failing-and-winning-at-...). Still, if a bug isn't taken on for x weeks or months, I'd say 99% of the time it never will be and can just as well be closed since it's ignored anyway.
- jasonpeacock 6y ago
  Yep, ShapeUp describes an open "Cool Down" period between cycles, where people are free to work on whatever they want - favorite bugs, features, docs, developer tools, etc. They discuss how everyone maintains their own personal list of what's important to them and use that to drive their work. But maintaining a single, centralized list of everything has little value. Anything important is already being tracked in the roadmap, including bugs impacting customers of sufficient priority. It really is worth reading the ShapeUp book, it provides a good, alternate view of commonly-held beliefs.
  - 6y ago

anitil 6y ago

That's what I've done with my email. It's either in my inbox, or 'archived'. Mentally much easier than deleting, but functionally the same