The author's tactic gives them a good sense of the project, common requests, and bugs over a long time period.
This context is really valuable when reasoning about the product or determining what's important to prioritize.
The issue with the "declare bankruptcy and important stuff will come back" is that you don't actually solve the underlying ruthless prioritization issue and very quickly end up in the exact same position.
You also irritate people that spent time writing up product issues for potentially important bugs by auto closing them (so many important things may not come back), but the bigger loss is that going through all of them gives you solid product historical context.
For what it's worth, the best PMs I know go through the backlog and understand what they're killing when they approach a project that's currently fucked. I think it has a positive side effect of giving them a lot of credibility too (as well as helping them ramp up).
I have to agree. There is nothing more demotivating for me than documenting a bug thoroughly, only to have it returned to me two months later as part of a bulk 'we didn't get to this in time' cleanup.
Issues for those teams usually 'best effort' isolation going forward, which compounds the issue.
Possibly worse is those small bugs that would just take a few hours to fix but never get prioritized, yet they still get pulled up for discussion week after week during whole team grooming-meetings. "what is this bug again?" Accumulating a total of more admin-time than solution time.
I think the oldest bug I've raised that's still open is this Webkit one from 2008 [1]. It still gets plaintive comments from various people every few years. A few more and it'll be going off to college.
And yet this is what several open source projects do, including VSCode. They've even automated the process. If there's no action on a bug for X amount of time it's auto-closed.
Yeah if you're deleting bugs older than 2 weeks then they're just gonna resurface and you're gonna have to classify them later, in an ongoing process lasting however many weeks. Might as well instead grab the bull by the horns and get the beast tamed right here and now.
> Yeah if you're deleting bugs older than 2 weeks then they're just gonna resurface
I mean, maybe not—you might lose the users impacted by the bug. Which from a company PoV is probably a loss, but depending on how broken incentives are may not be for the dev team.
This context is really valuable when reasoning about the product or determining what's important to prioritize.
The issue with the "declare bankruptcy and important stuff will come back" is that you don't actually solve the underlying ruthless prioritization issue and very quickly end up in the exact same position.
You also irritate people that spent time writing up product issues for potentially important bugs by auto closing them (so many important things may not come back), but the bigger loss is that going through all of them gives you solid product historical context.
For what it's worth, the best PMs I know go through the backlog and understand what they're killing when they approach a project that's currently fucked. I think it has a positive side effect of giving them a lot of credibility too (as well as helping them ramp up).