6 ms·

Little bit related: When I come into a company as CTO, and there are too many bugs, I just close all bugs older than 6 months. Usually that's more than 10% (and

Little bit related: When I come into a company as CTO, and there are too many bugs, I just close all bugs older than 6 months. Usually that's more than 10% (and the org wasn't capable or willing to fix them). Hasn't created any problems yet, but everyone feels better immediately (and we implement ways to not reach high bug levels again).

tinus_hn 4y ago
And as a plus, it teaches your customers not to waste their time filing bugs, so your stats look even better! A perfect example of management by excel sheet.
gspr 4y ago
Wh... why?
- dj_mc_merlin 4y ago
  > the org wasn't capable or willing to fix them Probably this. Can't fix everything, and the bugs piling up demoralizes many engineers. Six months is a bit low, I'd go higher, but there's no point having a bug on your board that you're not realistically actually going to fix.
  - gspr 4y ago
    But the proposed action isn't to fix the bugs, it's to delete the documentation of the bugs! Closing your eyes don't make a problem go away. Surely the engineers understand that too, and won't get a moral boost from ignoring the known problems.
    - KingOfCoders 4y ago
      I did not suggest to ignore the known problems: "and we implement ways to not reach high bug levels again" I suggest to close bug reports of bugs that will never get fixed.
      - gspr 4y ago
        > I suggest to close bug reports of bugs that will never get fixed. OK. We still disagree about whether that is smart, but one thing is sure: that's not what you wrote originally.
- rad_gruchalski 4y ago
  Because if they’re not resolved yet, there’s no client suffering from them in short term. If they suffer from such a bug, someone will raise it again.
  - speedgoose 4y ago
    Users don't always complain, they sometimes simply go away.
    - rad_gruchalski 4y ago
      Same outcome, no user to complain. When/if the bug reappears, it is reported again.
    - KingOfCoders 4y ago
      If an organisation is not willing to fix the bug, the customer will go away, if you have the bug in your bugtracker or not. Bugs in a bugtracker are not important. Fixed bugs are important. There is a distinction. Bugs in a bugtracker that are not fixed get you nowhere.
      - KingOfCoders 4y ago
        "And so are unfixed ones! I'd say even more so." It's better to not fix bugs than to fix them? "But the worst thing is to pretend the problem doesn't exist" No where did I pretend the problem does not exist. I wrote "and we implement ways to not reach high bug levels again" to fix the problem. I'm not advocating slashing all the bugs every month, or every year. I propose slashing bugs once when the reports got out of hand because of a bad bug culture and then implement better QA and bug fixing practices. This is the opposite of what you imply.
      - gspr 4y ago
        > Bugs in a bugtracker are not important. Your customers must be reeling at this! Do you really not think it's important to them that known flaws in the product are documented? > Fixed bugs are important. Sure. And so are unfixed ones! I'd say even more so. > Bugs in a bugtracker that are not fixed get you nowhere. Of course they do! The best thing, as you say, is to fix the problem. But the worst thing is to pretend the problem doesn't exist – documenting it is clearly better.
- ZephyrBlu 4y ago
  Can imagine it's for a lot of reasons. Like: - Improves morale - Focuses the team - Makes the task more approachable Etc. The important ones will probably bubble up again in due time.
  - gspr 4y ago
    > - Improves morale I'd buy this if the bug was actually gone. But it's not! Closing a bug report doesn't make the bug go away! > - Focuses the team A decent bug tracker should have priority levels for various bugs, surely. > - Makes the task more approachable I don't understand. Can you elaborate? > The important ones will probably bubble up again in due time. This seems like a terrible waste of everyone's time.
    - KingOfCoders 4y ago
      > I'd buy this if the bug was actually gone. But it's not! Closing a bug report doesn't make the bug go away! It does improve morale. Developers see a mountain of bugs they could never fix. > I don't understand. Can you elaborate? Say you have 100 bugs open for 10 developers, and you close all bugs older than 6 months. Then you go through the remaining one and close all the ones who have no impact ("css line should be 2 pixel but is one pixel") on customers and you get to 30. Then you implement (better) code reviews, phase injection analysis (in which phase a bug was introduced, E.g. missing requirement, and where it was found E.g. customer), enforce static tools (Clippy) policy. Then you do two bug fixing sprints and refactoring of code that gets a high amount of bugs and you have a manageable bug count of 10 (1/dev instead of 10/dev) which keeps low because of the quality improvements you made. > This seems like a terrible waste of everyone's time. No managing hundreds of bugs in a bugtracker that do not get fixed is a terrible waste of everyone's time.
      - gspr 4y ago
        > It does improve morale. Developers see a mountain of bugs they could never fix. So you propose that telling them that the mountain is gone will actually make them believe that it is? > No managing hundreds of bugs in a bugtracker that do not get fixed is a terrible waste of everyone's time. How do bug tracker entries waste people's time? Sure, confirming or fixing or otherwise working on a bug takes time, but that's hardly wasted. And if the bug just sits there, how does it waste time?
- eru 4y ago
  You can just archive the bugs somewhere, so you can open them again later if you want to. (You don't need to completely delete them or so.) I can see how this can provide psychological benefits to some people.
  - KingOfCoders 4y ago
    Yes, if the org is vehemently against it, you can create another project as a "bad bank".
    - eru 4y ago
      That might actually also be a good technical way to keep track of which bugs were already 'properly' closed, and which were only closed as part of the clean slate. (Depending on what kind of operations your bug tracker supports or doesn't support.)
- KingOfCoders 4y ago
  It enables the company to get to a different level of fixing bugs. Say you have 10+bugs/engineer, it's hard to realistically lower them. So you slash the number of bugs and that enables you to implement ways to keep the bug count low: fix-bug-first, code reviews, checklists, static tools, phase injection analysis, bug council, etc.
  - gspr 4y ago
    No! You slash the number of bug reports. The bugs are still there! Am I missing some joke here?
    - KingOfCoders 4y ago
      1. You don't know if they are still there. Thousands of commits have been done since then. Whenever I did go through a long list of old bugs, many were not reproduceable. 2. Many companies have no bug triage process and just fill every bug that is reported. So these are bugs that no one has any intention of fixing. So it's not important if they are there or not. 3. You seem to think that only the bugs in your bugtracker are there. They might be the minority of bugs in your code. Whenever I increase unit testing in my own code, I find dozens of bugs. I was once in a company that hired students during holidays for explorative testing. Dozens of bugs were found every time. The amount of bugs in your bugtracker depends on how much customers you have, how much they care and how big your QA effort is. It's nowhere the number of bugs in your application. The bugs in your bugtracker are a random selection with a bias to the more obvious ones of the bugs in your code. 4. If you don't want to fix bugs, you don't need to track them.
      - matkoniecz 4y ago
        If the closing was was purging of not reproduceable/low quality/useless bug reports then it would be different. Would 10 month old well documented report of critical security issue also would be closed after your purge?
        KingOfCoders 4y ago
neilv 4y ago
On the theory that the valid and important enough bugs would've been fixed within 6 months? Any idea the breakdown of the bugs that were closed? (Guesses at percentages of which were user error, applied only to an older version, duplicates, irreproducibile, valid but would happen only in freak circumstances, low impact, etc.)
- KingOfCoders 4y ago
  Yes. Many old bugs are no longer there, because dozens or hundreds of features have been built since upon the buggy code.
account42 4y ago
This might be an OK strategy for an internal bug tracker but for an open source project or something else with a public bug tracker just closing unresolved bugs is the best way to alienate your most dedicated users who have taken the time to file bug reports.
- KingOfCoders 4y ago
  Yes you're right, in an open source project the bug tracker helps developers understand why something doesn't work and if it's their problem or a library bug.
gpderetta 4y ago
This a well known bug handling workflow known as the "CADT Model".
- falcor84 4y ago
  Thank you, this was a fun read https://www.jwz.org/doc/cadt.html https://www.jwz.org/doc/cadt.html And it was particularly nice to see that is by Jamie Zawinski of Zawinski's Law fame: "Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can."
  - gpderetta 4y ago
    Directly linking to jwz from HN doesn't lead to the expected result though :)
    - falcor84 4y ago
      Sorry for being obtuse, but could you please explain what I'm missing. I hope to be one of today's lucky 10,000
      - cinntaile 4y ago
        Click on your link that you just posted.
      - newaccount74 4y ago
        If you click the link you see a picture of an egg that looks like a hairy testicle with a quote complaining about HN. (Assuming you use a browser that sends the referer header)
        falcor84 4y ago
        Lol. I don't know why, but apparently my browser isn't sending the referrer header, and I'm using vanilla chrome on Android. EDIT: Sorry, I think it might actually just be that because I first visited that page before coming in via HN, I've just been seeing the cached version of the real page, instead of the DDoS-protecting testicle.
eloop 4y ago
The age old ostrich approach!
- KingOfCoders 4y ago
  "and we implement ways to not reach high bug levels again"
ThePadawan 4y ago
I'm calling Poe's Law [0] on this one. I could 100% believe this is genuine, but I would also 100% believe this is a quote from a Dilbert-like comic strip. [0] https://en.wikipedia.org/wiki/Poe%27s_law https://en.wikipedia.org/wiki/Poe%27s_law
- bee_rider 4y ago
  The followup https://news.ycombinator.com/item?id=32734254 https://news.ycombinator.com/item?id=32734254 even retains the ambiguity. Magnificent.
  - ThePadawan 4y ago
    The ambiguity of referring to both the undesired code behaviors and the tickets tracking those issues as "the bugs" is giving me PTSD, too.
- KingOfCoders 4y ago
  Never saw myself as PHB :-)
  - deleted 4y ago
    [deleted]
kqr 4y ago
This is sometimes called a "bug bankrupcty". I'm not that convinced of its usefulness. Let's apply basic systems theory: if bugs are filed faster than they are resolved, the tendency of the open bug count is toward the infinite. You can declare bankruptcy but it won't change the dynamics of the system: bugs will keep piling up. So you may feel temporary relief, but the underlying problem is still there, causing stress. You could apply the rule more dynamically: all bugs older than X are always automatically demoted to wontfix status, on the basis that factually, they haven't actually been prioritised for a while. In this case you're using real-world prioritisation decisions to drive the prioritisation status in your bug tracker. This is a more stable solution. ---- But here's where you can take it to the next level. You're de-prioritising a bug for 6 months and then automatically marking it as wontfix. Using "open for 6 months" as the signal to wontfix a bug is relying on a lagging signal. It would be nice with a leading signal instead, so that you can mark it as wontfix immediately as soon as you know it won't be fixed for six months. How do you know which bugs fall into the wontfix category immediately? Here's one way: Make note of the average rate of commits the team is capable of, and decide how much of their time they should spend on bugs, and call the product of that M. Let's say you like the 6 month wontfix threshold, and call this time W. Apply Little's law: L = M*W L is the number of open bugs you can have. Find the top L bugs, and mark the rest as wontfix (or the lowest priority level, depending on what angers your users less.) Concrete example: my previous team committed stuff at a rate of 6.2/day. They spent 30 % of their time fixing bugs. That's roughly 1.9 bug fixed per day. Six months is on average something like 110 workdays. All in all 1.9 * 110 ~= 200 bugs can be open with this the team at any given time. Anything other than the most important 200 gets marked wontfix immediately. ---- You might complain that it's difficult to say that a bug is less important than 200 other bugs, and you'd be right. Based on my experience, I'd run this with two priority levels and much stricter thresholds. When I have run the analysis on internal bug databases, bugs that are allowed to linger for more than a month are very rarely fixed anyway. When you have stricter thresholds, you can't just mark everything else "wontfix", because it makes your users angry when it seems like you won't even bother with most of their reported bugs, so you have to add a third priority level that serves as the "probablywontfix" bucket in practise. - Priority 1 bugs should be fixed within a week, - Priority 2 bugs should be fixed within a month. - Priority 3 bugs come without any sort of SLO. How many open bugs can we have of the priority levels? Same sort of reasoning, but we also need to allocate effort toward priority 1 and priority 2. Let's say 50/50 because I haven't tried evaluating the optimal split. - Priority 1 bugs open: 1.9 bugs/day * 0.5 * 5 days ~= 5 open bugs - Priority 2 bugs open: 1.9 bugs/day * 0.5 * 22 days ~= 20 open bugs - Priority 3 bugs open: everything else. This you can actually work with.
cma 4y ago
Boeing?
yourapostasy 4y ago
This approach flattens the complexity of bugs into a single value, then measures the importance of bugs by a loosely-correlated, highly-noisy signal: time in queue. This is also why a recent client dumped a decades-long vendor in an enterprise setting that by proxy implemented this approach through a newly-offshored support team that didn't understand the product and stalled on difficult bugs until the bug reports died on the vine even after repeated executive meetings. Ask the account executive how they felt about losing out on an easy seven-figure annual renewal to a rival who won't likely come up for displacement until after the account exec retires. To add to the sting, the displacement came at a time that the role of the software product was planned for a big expansion. The tab for more licenses and the work was so high but close enough between the incumbent and challenger that it opened the door...and there went an 8-figure year for the incumbent's account executive. Decades of brand-building and relationship management down the tubes all so some support department head can show off on their scope's bottom line. We understood these were challenging problems to solve, were patient, and willing to put in the significant person-months of time it would take to help solve them. Client leadership however, was not willing to just get indefinitely shuffled onto the bug queue. We're not stupid. We know what being blown off looks like. We know when we're talking with a Regex Support organization versus a Semantic Support organization. The lag time between realizing that and acting upon it might take a few years, but once it happens in enterprise software, vendors rarely get another shot within another decade.
newaccount74 4y ago
As someone who takes a lot of care to document bugs, I would quit if you did that to my bugs. If something isn't reproducible anymore, fine, close it. But just closing stuff that nobody got around to fixing yet is evil.
- KingOfCoders 4y ago
  Usually people don't quit when I join and are rather happy that problems are solved instead of not solved. I would also not sit at my desk one day, and close all the bugs - but talk to developers, managers, leads, QA and product on how we solve the bug problems together. Slashing the number of bugs in the bugtracker is only one task and people didn't object but agreed to it as a way forward. I created by first bugs 40 years ago, I've created bugs that brought down sites and have been a tech manager for 25+ years learning on the way on how to deal with bugs. From my experience: "fixing yet" this is the problem. It's not "yet" it's "ever". If a company doesn't fix bugs in 6 or 12 months, it's never spending enough time to fix these bugs because new feature development is always more important. With the slashing of the bugs and a different approach to quality (E.g. fix bugs first) I would assume you're much happier that the bugs you report get fixed and developers are happy for your good bug reports than bug reports sitting in a bug tracker who no one acts upon.
  - mpol 4y ago
    > ...rather happy that problems are solved instead of not solved. But they are not solved, are they? > With the slashing of the bugs... And it's not slashing bugs, but slashing bug reports. The bugs are still there.
    - everforward 4y ago
      I would say that closing the bugs as WONTFIX is just changing the specs of the application so it's not a bug anymore. E.g. if you've got a bug that emojis cause an endpoint to throw a 500, closing the bug as WONTFIX is akin to just saying that emojis are invalid input to the application. After 6 months or a year, that's how everyone is treating it anyways.
TomSwirly 4y ago
> I just close all bugs older than 6 months [...] everyone feels better immediately I mean, people would feel even better if you just closed all the bugs, right? Some of the oldest unclosed bug reports are the most valuable. because they document long-standing pain points. Not that you would know... :-) If there were, say, 300 open bugs, you and 4 other people go through and triage them. ("You get bugs whose numbers are 0 mod 5, I get bugs wholes numbers are 1 mod 5", ... ) Organizing lots of tiny bugs into an omnibus bug is also great if all the tasks can be done at the same time. "OMNIBUS: fix help messages. See.... (list of a dozen old closed bugs)"
- KingOfCoders 4y ago
  "Some of the oldest unclosed bug reports are the most valuable. because they document long-standing pain points." Say there is a bug, "The line should be 2 em high" and the bug is not fixed for 6+ months, how is this more valuable because it's older? Yes, I would agree with the triage, and do it if possible. If an organisation is unwilling to spend resources to fix bugs, a triage doesn't work. It's the same with this 100 item backlogs, people put things in backlogs at position 20+ that are never developed but suggest they are developed, reducing immediate pain ("No, we're not going to develop this") but trading it for long term pain ("No, it's not in the next Sprint"). Yes, aggregating bugs into an OMNIBUS or aggregating bugs into a feature as requirements is valuable too.
  - bee_rider 4y ago
    "The line should be 2 em high" seems more like a feature request or... like just a general whining, than a bug. Your strategy of just closing these is probably valid. But I would call it "closing non-bug complaints which abuse the bug tracker," not slashing bugs. The reason people are so confused here, I think, is because to programmers, bugs are incorrect behavior of the program. These bugs exist whether they are reported or not. Removing bug reports does not remove bugs. In other comments you mention "and we implement ways to not reach high bug levels again." Is it possible that from a programmer's point of view, you are actually enforcing proper use of the bug tracker? i.e., keeping graphic design opinions about line widths out of it.
caboteria 4y ago
When I buy a second-hand car, if there's a warning light on the instrument panel I put a piece of electrician's tape over it. Hasn't created any problems yet, but everyone feels better immediately.
- KingOfCoders 4y ago
  When my leg is broken, I write a report and it feels much better already.

tinus_hn 4y ago

And as a plus, it teaches your customers not to waste their time filing bugs, so your stats look even better! A perfect example of management by excel sheet.

gspr 4y ago

Wh... why?

dj_mc_merlin 4y ago
> the org wasn't capable or willing to fix them Probably this. Can't fix everything, and the bugs piling up demoralizes many engineers. Six months is a bit low, I'd go higher, but there's no point having a bug on your board that you're not realistically actually going to fix.
- gspr 4y ago
  But the proposed action isn't to fix the bugs, it's to delete the documentation of the bugs! Closing your eyes don't make a problem go away. Surely the engineers understand that too, and won't get a moral boost from ignoring the known problems.
  - KingOfCoders 4y ago
    I did not suggest to ignore the known problems: "and we implement ways to not reach high bug levels again" I suggest to close bug reports of bugs that will never get fixed.
    - gspr 4y ago
      > I suggest to close bug reports of bugs that will never get fixed. OK. We still disagree about whether that is smart, but one thing is sure: that's not what you wrote originally.
rad_gruchalski 4y ago
Because if they’re not resolved yet, there’s no client suffering from them in short term. If they suffer from such a bug, someone will raise it again.
- speedgoose 4y ago
  Users don't always complain, they sometimes simply go away.
  - rad_gruchalski 4y ago
    Same outcome, no user to complain. When/if the bug reappears, it is reported again.
  - KingOfCoders 4y ago
    If an organisation is not willing to fix the bug, the customer will go away, if you have the bug in your bugtracker or not. Bugs in a bugtracker are not important. Fixed bugs are important. There is a distinction. Bugs in a bugtracker that are not fixed get you nowhere.
    - KingOfCoders 4y ago
      "And so are unfixed ones! I'd say even more so." It's better to not fix bugs than to fix them? "But the worst thing is to pretend the problem doesn't exist" No where did I pretend the problem does not exist. I wrote "and we implement ways to not reach high bug levels again" to fix the problem. I'm not advocating slashing all the bugs every month, or every year. I propose slashing bugs once when the reports got out of hand because of a bad bug culture and then implement better QA and bug fixing practices. This is the opposite of what you imply.
    - gspr 4y ago
      > Bugs in a bugtracker are not important. Your customers must be reeling at this! Do you really not think it's important to them that known flaws in the product are documented? > Fixed bugs are important. Sure. And so are unfixed ones! I'd say even more so. > Bugs in a bugtracker that are not fixed get you nowhere. Of course they do! The best thing, as you say, is to fix the problem. But the worst thing is to pretend the problem doesn't exist – documenting it is clearly better.
ZephyrBlu 4y ago
Can imagine it's for a lot of reasons. Like: - Improves morale - Focuses the team - Makes the task more approachable Etc. The important ones will probably bubble up again in due time.
- gspr 4y ago
  > - Improves morale I'd buy this if the bug was actually gone. But it's not! Closing a bug report doesn't make the bug go away! > - Focuses the team A decent bug tracker should have priority levels for various bugs, surely. > - Makes the task more approachable I don't understand. Can you elaborate? > The important ones will probably bubble up again in due time. This seems like a terrible waste of everyone's time.
  - KingOfCoders 4y ago
    > I'd buy this if the bug was actually gone. But it's not! Closing a bug report doesn't make the bug go away! It does improve morale. Developers see a mountain of bugs they could never fix. > I don't understand. Can you elaborate? Say you have 100 bugs open for 10 developers, and you close all bugs older than 6 months. Then you go through the remaining one and close all the ones who have no impact ("css line should be 2 pixel but is one pixel") on customers and you get to 30. Then you implement (better) code reviews, phase injection analysis (in which phase a bug was introduced, E.g. missing requirement, and where it was found E.g. customer), enforce static tools (Clippy) policy. Then you do two bug fixing sprints and refactoring of code that gets a high amount of bugs and you have a manageable bug count of 10 (1/dev instead of 10/dev) which keeps low because of the quality improvements you made. > This seems like a terrible waste of everyone's time. No managing hundreds of bugs in a bugtracker that do not get fixed is a terrible waste of everyone's time.
    - gspr 4y ago
      > It does improve morale. Developers see a mountain of bugs they could never fix. So you propose that telling them that the mountain is gone will actually make them believe that it is? > No managing hundreds of bugs in a bugtracker that do not get fixed is a terrible waste of everyone's time. How do bug tracker entries waste people's time? Sure, confirming or fixing or otherwise working on a bug takes time, but that's hardly wasted. And if the bug just sits there, how does it waste time?
eru 4y ago
You can just archive the bugs somewhere, so you can open them again later if you want to. (You don't need to completely delete them or so.) I can see how this can provide psychological benefits to some people.
- KingOfCoders 4y ago
  Yes, if the org is vehemently against it, you can create another project as a "bad bank".
  - eru 4y ago
    That might actually also be a good technical way to keep track of which bugs were already 'properly' closed, and which were only closed as part of the clean slate. (Depending on what kind of operations your bug tracker supports or doesn't support.)
KingOfCoders 4y ago
It enables the company to get to a different level of fixing bugs. Say you have 10+bugs/engineer, it's hard to realistically lower them. So you slash the number of bugs and that enables you to implement ways to keep the bug count low: fix-bug-first, code reviews, checklists, static tools, phase injection analysis, bug council, etc.
- gspr 4y ago
  No! You slash the number of bug reports. The bugs are still there! Am I missing some joke here?
  - KingOfCoders 4y ago
    1. You don't know if they are still there. Thousands of commits have been done since then. Whenever I did go through a long list of old bugs, many were not reproduceable. 2. Many companies have no bug triage process and just fill every bug that is reported. So these are bugs that no one has any intention of fixing. So it's not important if they are there or not. 3. You seem to think that only the bugs in your bugtracker are there. They might be the minority of bugs in your code. Whenever I increase unit testing in my own code, I find dozens of bugs. I was once in a company that hired students during holidays for explorative testing. Dozens of bugs were found every time. The amount of bugs in your bugtracker depends on how much customers you have, how much they care and how big your QA effort is. It's nowhere the number of bugs in your application. The bugs in your bugtracker are a random selection with a bias to the more obvious ones of the bugs in your code. 4. If you don't want to fix bugs, you don't need to track them.
    - matkoniecz 4y ago
      If the closing was was purging of not reproduceable/low quality/useless bug reports then it would be different. Would 10 month old well documented report of critical security issue also would be closed after your purge?
      - KingOfCoders 4y ago

neilv 4y ago

On the theory that the valid and important enough bugs would've been fixed within 6 months? Any idea the breakdown of the bugs that were closed? (Guesses at percentages of which were user error, applied only to an older version, duplicates, irreproducibile, valid but would happen only in freak circumstances, low impact, etc.)

KingOfCoders 4y ago
Yes. Many old bugs are no longer there, because dozens or hundreds of features have been built since upon the buggy code.

account42 4y ago

This might be an OK strategy for an internal bug tracker but for an open source project or something else with a public bug tracker just closing unresolved bugs is the best way to alienate your most dedicated users who have taken the time to file bug reports.

KingOfCoders 4y ago
Yes you're right, in an open source project the bug tracker helps developers understand why something doesn't work and if it's their problem or a library bug.

gpderetta 4y ago

This a well known bug handling workflow known as the "CADT Model".

falcor84 4y ago
Thank you, this was a fun read https://www.jwz.org/doc/cadt.html https://www.jwz.org/doc/cadt.html And it was particularly nice to see that is by Jamie Zawinski of Zawinski's Law fame: "Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can."
- gpderetta 4y ago
  Directly linking to jwz from HN doesn't lead to the expected result though :)
  - falcor84 4y ago
    Sorry for being obtuse, but could you please explain what I'm missing. I hope to be one of today's lucky 10,000
    - cinntaile 4y ago
      Click on your link that you just posted.
    - newaccount74 4y ago
      If you click the link you see a picture of an egg that looks like a hairy testicle with a quote complaining about HN. (Assuming you use a browser that sends the referer header)
      - falcor84 4y ago
        Lol. I don't know why, but apparently my browser isn't sending the referrer header, and I'm using vanilla chrome on Android. EDIT: Sorry, I think it might actually just be that because I first visited that page before coming in via HN, I've just been seeing the cached version of the real page, instead of the DDoS-protecting testicle.

eloop 4y ago

The age old ostrich approach!

KingOfCoders 4y ago
"and we implement ways to not reach high bug levels again"

ThePadawan 4y ago

I'm calling Poe's Law [0] on this one. I could 100% believe this is genuine, but I would also 100% believe this is a quote from a Dilbert-like comic strip. [0] https://en.wikipedia.org/wiki/Poe%27s_law https://en.wikipedia.org/wiki/Poe%27s_law

bee_rider 4y ago
The followup https://news.ycombinator.com/item?id=32734254 https://news.ycombinator.com/item?id=32734254 even retains the ambiguity. Magnificent.
- ThePadawan 4y ago
  The ambiguity of referring to both the undesired code behaviors and the tickets tracking those issues as "the bugs" is giving me PTSD, too.
KingOfCoders 4y ago
Never saw myself as PHB :-)
- deleted 4y ago
  [deleted]

kqr 4y ago

This is sometimes called a "bug bankrupcty". I'm not that convinced of its usefulness. Let's apply basic systems theory: if bugs are filed faster than they are resolved, the tendency of the open bug count is toward the infinite. You can declare bankruptcy but it won't change the dynamics of the system: bugs will keep piling up. So you may feel temporary relief, but the underlying problem is still there, causing stress. You could apply the rule more dynamically: all bugs older than X are always automatically demoted to wontfix status, on the basis that factually, they haven't actually been prioritised for a while. In this case you're using real-world prioritisation decisions to drive the prioritisation status in your bug tracker. This is a more stable solution. ---- But here's where you can take it to the next level. You're de-prioritising a bug for 6 months and then automatically marking it as wontfix. Using "open for 6 months" as the signal to wontfix a bug is relying on a lagging signal. It would be nice with a leading signal instead, so that you can mark it as wontfix immediately as soon as you know it won't be fixed for six months. How do you know which bugs fall into the wontfix category immediately? Here's one way: Make note of the average rate of commits the team is capable of, and decide how much of their time they should spend on bugs, and call the product of that M. Let's say you like the 6 month wontfix threshold, and call this time W. Apply Little's law: L = M*W L is the number of open bugs you can have. Find the top L bugs, and mark the rest as wontfix (or the lowest priority level, depending on what angers your users less.) Concrete example: my previous team committed stuff at a rate of 6.2/day. They spent 30 % of their time fixing bugs. That's roughly 1.9 bug fixed per day. Six months is on average something like 110 workdays. All in all 1.9 * 110 ~= 200 bugs can be open with this the team at any given time. Anything other than the most important 200 gets marked wontfix immediately. ---- You might complain that it's difficult to say that a bug is less important than 200 other bugs, and you'd be right. Based on my experience, I'd run this with two priority levels and much stricter thresholds. When I have run the analysis on internal bug databases, bugs that are allowed to linger for more than a month are very rarely fixed anyway. When you have stricter thresholds, you can't just mark everything else "wontfix", because it makes your users angry when it seems like you won't even bother with most of their reported bugs, so you have to add a third priority level that serves as the "probablywontfix" bucket in practise. - Priority 1 bugs should be fixed within a week, - Priority 2 bugs should be fixed within a month. - Priority 3 bugs come without any sort of SLO. How many open bugs can we have of the priority levels? Same sort of reasoning, but we also need to allocate effort toward priority 1 and priority 2. Let's say 50/50 because I haven't tried evaluating the optimal split. - Priority 1 bugs open: 1.9 bugs/day * 0.5 * 5 days ~= 5 open bugs - Priority 2 bugs open: 1.9 bugs/day * 0.5 * 22 days ~= 20 open bugs - Priority 3 bugs open: everything else. This you can actually work with.

cma 4y ago

Boeing?

yourapostasy 4y ago

This approach flattens the complexity of bugs into a single value, then measures the importance of bugs by a loosely-correlated, highly-noisy signal: time in queue. This is also why a recent client dumped a decades-long vendor in an enterprise setting that by proxy implemented this approach through a newly-offshored support team that didn't understand the product and stalled on difficult bugs until the bug reports died on the vine even after repeated executive meetings. Ask the account executive how they felt about losing out on an easy seven-figure annual renewal to a rival who won't likely come up for displacement until after the account exec retires. To add to the sting, the displacement came at a time that the role of the software product was planned for a big expansion. The tab for more licenses and the work was so high but close enough between the incumbent and challenger that it opened the door...and there went an 8-figure year for the incumbent's account executive. Decades of brand-building and relationship management down the tubes all so some support department head can show off on their scope's bottom line. We understood these were challenging problems to solve, were patient, and willing to put in the significant person-months of time it would take to help solve them. Client leadership however, was not willing to just get indefinitely shuffled onto the bug queue. We're not stupid. We know what being blown off looks like. We know when we're talking with a Regex Support organization versus a Semantic Support organization. The lag time between realizing that and acting upon it might take a few years, but once it happens in enterprise software, vendors rarely get another shot within another decade.

newaccount74 4y ago

As someone who takes a lot of care to document bugs, I would quit if you did that to my bugs. If something isn't reproducible anymore, fine, close it. But just closing stuff that nobody got around to fixing yet is evil.

KingOfCoders 4y ago
Usually people don't quit when I join and are rather happy that problems are solved instead of not solved. I would also not sit at my desk one day, and close all the bugs - but talk to developers, managers, leads, QA and product on how we solve the bug problems together. Slashing the number of bugs in the bugtracker is only one task and people didn't object but agreed to it as a way forward. I created by first bugs 40 years ago, I've created bugs that brought down sites and have been a tech manager for 25+ years learning on the way on how to deal with bugs. From my experience: "fixing yet" this is the problem. It's not "yet" it's "ever". If a company doesn't fix bugs in 6 or 12 months, it's never spending enough time to fix these bugs because new feature development is always more important. With the slashing of the bugs and a different approach to quality (E.g. fix bugs first) I would assume you're much happier that the bugs you report get fixed and developers are happy for your good bug reports than bug reports sitting in a bug tracker who no one acts upon.
- mpol 4y ago
  > ...rather happy that problems are solved instead of not solved. But they are not solved, are they? > With the slashing of the bugs... And it's not slashing bugs, but slashing bug reports. The bugs are still there.
  - everforward 4y ago
    I would say that closing the bugs as WONTFIX is just changing the specs of the application so it's not a bug anymore. E.g. if you've got a bug that emojis cause an endpoint to throw a 500, closing the bug as WONTFIX is akin to just saying that emojis are invalid input to the application. After 6 months or a year, that's how everyone is treating it anyways.

TomSwirly 4y ago

> I just close all bugs older than 6 months [...] everyone feels better immediately I mean, people would feel even better if you just closed all the bugs, right? Some of the oldest unclosed bug reports are the most valuable. because they document long-standing pain points. Not that you would know... :-) If there were, say, 300 open bugs, you and 4 other people go through and triage them. ("You get bugs whose numbers are 0 mod 5, I get bugs wholes numbers are 1 mod 5", ... ) Organizing lots of tiny bugs into an omnibus bug is also great if all the tasks can be done at the same time. "OMNIBUS: fix help messages. See.... (list of a dozen old closed bugs)"

KingOfCoders 4y ago
"Some of the oldest unclosed bug reports are the most valuable. because they document long-standing pain points." Say there is a bug, "The line should be 2 em high" and the bug is not fixed for 6+ months, how is this more valuable because it's older? Yes, I would agree with the triage, and do it if possible. If an organisation is unwilling to spend resources to fix bugs, a triage doesn't work. It's the same with this 100 item backlogs, people put things in backlogs at position 20+ that are never developed but suggest they are developed, reducing immediate pain ("No, we're not going to develop this") but trading it for long term pain ("No, it's not in the next Sprint"). Yes, aggregating bugs into an OMNIBUS or aggregating bugs into a feature as requirements is valuable too.
- bee_rider 4y ago
  "The line should be 2 em high" seems more like a feature request or... like just a general whining, than a bug. Your strategy of just closing these is probably valid. But I would call it "closing non-bug complaints which abuse the bug tracker," not slashing bugs. The reason people are so confused here, I think, is because to programmers, bugs are incorrect behavior of the program. These bugs exist whether they are reported or not. Removing bug reports does not remove bugs. In other comments you mention "and we implement ways to not reach high bug levels again." Is it possible that from a programmer's point of view, you are actually enforcing proper use of the bug tracker? i.e., keeping graphic design opinions about line widths out of it.

caboteria 4y ago

When I buy a second-hand car, if there's a warning light on the instrument panel I put a piece of electrician's tape over it. Hasn't created any problems yet, but everyone feels better immediately.

KingOfCoders 4y ago
When my leg is broken, I write a report and it feels much better already.