3 ms·

This is silly. Why is having an ever-increasing number of open items bad? As long as you have a way to prioritize them, it is only beneficial to have a large l

This is silly. Why is having an ever-increasing number of open items bad? As long as you have a way to prioritize them, it is only beneficial to have a large list of issues. Those issues exist in some abstract sense whether or not you acknowledge them in an issue tracker.

zer00eyz 11y ago
"If you look around and everything is on fire and your application seems to be about to collapse into the sea AND you produce a graph like this from your tracker, it's a sign of a real problem that needs to be dealt with right away." Would be a clear indication that this isn't the heathy version that you describe but rather the unhealthy version the author suggests. At some point your bug tracker becomes noise and you just never deal with it. I have seen it happen, and cleaning it up is a whole separate set of pain.
- harryf 11y ago
  > At some point your bug tracker becomes noise and you just never deal with it. Judging from the graph it looks like Jira is the tracker in this essay. There's so much horrible UX in Jira it's very likely to be part of the problem. Coping with any volume of bulk data in Jira is a nightmare - for a PM or engineering manager you end up having to most of the prioritization in your head. I'd like to see issue tracking tools on the market that take what we've learned about data visualization in fields like data journalism. Some of the UI elements of OpenRefine, for example, would be huge step forward
erikpukinskis 11y ago
The basic principle is minimizing "work in progress", which is an idea that comes from the Kanban production model. It's certainly worth questioning whether it applies to software... I suspect the idea behind your thought is that there is no inventory cost to issues since they are just a few bits on a hard drive somewhere. But I'm not so sure that's true. Every minute that passes after a bug report has costs: the reporter's memory slowly degrades making it harder to reconstruct the triggering scenario. The software itself slowly drifts away from the state the bug was filed in, adding questions about whether it's still applicable. And recent changes to the codebase that might have triggered the bug also slowly fade from developers' memory. Lastly the larger the bug database is, the harder it is to search and the slower de-duping becomes. In a real sense the value of the report decreases AND the cost of addressing it increases over time.
- sandal 11y ago
  Spot on. These were huge issues in the organization I'm describing in this essay.

zer00eyz 11y ago

"If you look around and everything is on fire and your application seems to be about to collapse into the sea AND you produce a graph like this from your tracker, it's a sign of a real problem that needs to be dealt with right away." Would be a clear indication that this isn't the heathy version that you describe but rather the unhealthy version the author suggests. At some point your bug tracker becomes noise and you just never deal with it. I have seen it happen, and cleaning it up is a whole separate set of pain.

harryf 11y ago
> At some point your bug tracker becomes noise and you just never deal with it. Judging from the graph it looks like Jira is the tracker in this essay. There's so much horrible UX in Jira it's very likely to be part of the problem. Coping with any volume of bulk data in Jira is a nightmare - for a PM or engineering manager you end up having to most of the prioritization in your head. I'd like to see issue tracking tools on the market that take what we've learned about data visualization in fields like data journalism. Some of the UI elements of OpenRefine, for example, would be huge step forward

erikpukinskis 11y ago

The basic principle is minimizing "work in progress", which is an idea that comes from the Kanban production model. It's certainly worth questioning whether it applies to software... I suspect the idea behind your thought is that there is no inventory cost to issues since they are just a few bits on a hard drive somewhere. But I'm not so sure that's true. Every minute that passes after a bug report has costs: the reporter's memory slowly degrades making it harder to reconstruct the triggering scenario. The software itself slowly drifts away from the state the bug was filed in, adding questions about whether it's still applicable. And recent changes to the codebase that might have triggered the bug also slowly fade from developers' memory. Lastly the larger the bug database is, the harder it is to search and the slower de-duping becomes. In a real sense the value of the report decreases AND the cost of addressing it increases over time.

sandal 11y ago
Spot on. These were huge issues in the organization I'm describing in this essay.