Hacker News Reader

Comment by berkes | Hacker News Reader

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

View on HN

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.

https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...

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.

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.

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/

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

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

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.

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

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.

ShapeUp is great! I don't think a cool-down phase is good though – if something is important to someone and it is indeed important for the business but still doesn't get planned in any iterations that means either

a) it's not actually important compared to other things so having someone work on it in a cool down phase is likely not well-spent time

b) there is a dysfunctional team/organization in which important stuff doesn't get prioritized correctly (typical example for this being 100% product management driven organizations in which refactorings etc. never get any time assigned)

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

Reply on news.ycombinator.com