Hacker News Reader

Comment by rufius | Hacker News Reader

Honestly, I’d have approached it differently.

Close everything older than 2 weeks. If it’s important/relevant, it will crop back up. If it’s not, then it stays unfixed.

This can be really uncomfortable to do. But it’s how I’ve rescued a couple of teams that I’ve led as either an EM or Tech Lead.

Put another way - if everything is important or “must fix”, nothing is.

So to the author: that seemed like a waste of time. I would not have done it because I’m not convinced the outcome would have been meaningfully different from my tactic.

View on HN

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.

A bug left alone long enough grows from an child bug to an adult bug. You're still caring, feeding, and maintaining that bug the entire 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.

[1] https://bugs.webkit.org/show_bug.cgi?id=22261

> We are fixing in Blink (c2103)

That's no help for Safari. Personally I haven't needed to care about Safari in half a decade, but presumably others still do.

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.

I can see it cut both ways.

I won’t argue that my way is the only correct way because I’m certain it’s not.

Something I didn’t make clear in the very brief description I gave was that, yes, capturing context of what was there is important.

That said - the two projects I worked in where we did this were filled with bad bugs (a separate and problematic issue).

Nothing really replaces spending time with users. That’s what I tend to opt for - figuring out what sucks in their experience and iterate on that.

We're doing it in my current company and we lose a lot of valuable data. On top of this, other teams are not encouraged opening a bug anymore because no-one will fix it.

It's great for individual contributors who don't care about understanding the product and are probably going to be in another team in 3 months.

In a previous job I did what the author did and it helped building an understanding of the project and with knowing at any time the list of the top X things we had to fix.

I've found a happy medium is to have a garbage collection section of the backlog. You'll probably never touch it, but having the data can be important.

> Close everything older than 2 weeks. If it’s important/relevant, it will crop back up. If it’s not, then it stays unfixed.

This seems like a great idea: technical debt bankruptcy.

In reality, you're throwing away hugely valuable data that people spent real time and effort producing for you.

Note: you'll probably want to copy/paste that URL instead of clicking it, because unless something has changed (e.g. browsers not sending referrers), JWZ had/has a Referrer rule that will show something...else for anyone coming from HN.

https://hn.algolia.com/?dateRange=pastMonth&page=0&prefix=tr...

That's half the fun of legitimate opportunities to link jwz's content. :D

Thanks, I'd forgotten all about that, and also why jwz's domain was resolving to 127.0.0.X on my system.

Ahh, the infuriation of seeing the issue you worked hard to document, closed by summarily by somebody that didn't even try to understand.

And of course that person didn't close their pet project or the features they promised.

It's slightly soothed when it's realized one of your summarily closed bugs could have prevented the next incident or major customer loss.

I'm very late to the discussion here, but I find this to be a terrible approach.

If I write a bug report, I'm doing the developers a favor by pointing out where they failed in development and validation. Simply closing the report with no action tells me that you don't care about the quality of your code or the way it affects the users; and that I've wasted my time thinking that you did care and writing up the bug.

Well, infuriating when you're a client of teams who use this strategy, but it is certainly effective.

Reply on news.ycombinator.com