9 ms·

Wh... why?

by 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.
- gspr 4y ago
  > Because if they’re not resolved yet, there’s no client suffering from them in short term. This seems like an unrealistically perfect product. > If they suffer from such a bug, someone will raise it again. And this seems terrible for everyone involved. Terrible for the customers who have to nag, stay "on the ball" and make sure bugs get re-filed, and terrible for the developers who have to figure out which old (fake-closed) bug reports actually match the new filings.
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

Wh... why?

by gspr 4y ago

Wh... why?

> 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.
gspr 4y ago
> Because if they’re not resolved yet, there’s no client suffering from them in short term. This seems like an unrealistically perfect product. > If they suffer from such a bug, someone will raise it again. And this seems terrible for everyone involved. Terrible for the customers who have to nag, stay "on the ball" and make sure bugs get re-filed, and terrible for the developers who have to figure out which old (fake-closed) bug reports actually match the new filings.

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