4 ms·

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

by rufius 6y ago

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.

fossuser 6y ago
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).
- EmptyMoon 6y ago
  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.
  - pixl97 6y ago
    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.
    - mrec 6y ago
      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 https://bugs.webkit.org/show_bug.cgi?id=22261
      - edoceo 6y ago
        > We are fixing in Blink (c2103)
        mrec 6y ago
        That's no help for Safari. Personally I haven't needed to care about Safari in half a decade, but presumably others still do.
  - greggman3 6y ago
    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.
  - Too 6y ago
    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.
- spurgu 6y ago
  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.
  - dragonwriter 6y ago
    > 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.
- rufius 6y ago
  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.
sneak 6y ago
> 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. See also: https://www.jwz.org/doc/cadt.html https://www.jwz.org/doc/cadt.html
- nitrogen 6y ago
  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=true&query=jwz%20copy%2Fpaste&sort=byPopularity&type=comment https://hn.algolia.com/?dateRange=pastMonth&page=0&prefix=tr...
  - sneak 6y ago
    That's half the fun of legitimate opportunities to link jwz's content. :D
  - boring_twenties 6y ago
    Thanks, I'd forgotten all about that, and also why jwz's domain was resolving to 127.0.0.X on my system.
jokethrowaway 6y ago
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.
- SkyPuncher 6y ago
  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.
emodendroket 6y ago
Well, infuriating when you're a client of teams who use this strategy, but it is certainly effective.
glennpratt 6y ago
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.
unbalancedevh 5y ago
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.

by rufius 6y ago

fossuser 6y ago

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

EmptyMoon 6y ago
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.
- pixl97 6y ago
  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.
  - mrec 6y ago
    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 https://bugs.webkit.org/show_bug.cgi?id=22261
    - edoceo 6y ago
      > We are fixing in Blink (c2103)
      - mrec 6y ago
        That's no help for Safari. Personally I haven't needed to care about Safari in half a decade, but presumably others still do.
- greggman3 6y ago
  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.
- Too 6y ago
  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.
spurgu 6y ago
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.
- dragonwriter 6y ago
  > 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.
rufius 6y ago
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.

sneak 6y ago

> 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. See also: https://www.jwz.org/doc/cadt.html https://www.jwz.org/doc/cadt.html

nitrogen 6y ago
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=true&query=jwz%20copy%2Fpaste&sort=byPopularity&type=comment https://hn.algolia.com/?dateRange=pastMonth&page=0&prefix=tr...
- sneak 6y ago
  That's half the fun of legitimate opportunities to link jwz's content. :D
- boring_twenties 6y ago
  Thanks, I'd forgotten all about that, and also why jwz's domain was resolving to 127.0.0.X on my system.

jokethrowaway 6y ago

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.

SkyPuncher 6y ago
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.

emodendroket 6y ago

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

glennpratt 6y ago

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.

unbalancedevh 5y ago

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.