81–90 of 117 posts
Earlier quoted context omitted.
Wh... why?
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.
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).
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
Earlier quoted context omitted.
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.
> - 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.
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.
Earlier quoted context omitted.
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.
No! You slash the number of bug reports . The bugs are still there! Am I missing some joke here?
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.
Earlier quoted context omitted.
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.
Users don't always complain, they sometimes simply go away.
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.
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).
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.
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.
Earlier quoted context omitted.
Users don't always complain, they sometimes simply go away.
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.
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.
Earlier quoted context omitted.
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.
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 4…
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.
Earlier quoted context omitted.
Users don't always complain, they sometimes simply go away.
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.
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.
Earlier quoted context omitted.
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 4…
> ...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.
You might have overseen
"and we implement ways to not reach high bug levels again"