3 ms·

The core problem is that "number of issues" is not a meaningful metric, "rate at which business value created" is. At it's core, I believe an issue tracker is

The core problem is that "number of issues" is not a meaningful metric, "rate at which business value created" is. At it's core, I believe an issue tracker is fundamentally the wrong pattern for developing software and the same pathologies crop up over and over again. Issue trackers seek to accomplish multiple goals: They are communication mechanism between departments, they're a way of tracking the state of progress, they're a means of prioritization and they're a way of evaluating progress. Because these goals lie fundamentally in tension with each other, the same problems predictably occur with long time use of an issue tracker. Issue trackers are like shopping lists without price tags. if you imagine an Amazon Wishlist with all the things you want to buy in life, it's not hard to imagine the same graph appearing. Somewhere mixed into all those items is a ferrari and also the washer you need to stop your tap from leaking. And, of course, the list is going to get exponentially longer as time goes on, even as you check items off. But the reason we don't get stressed about our ever expanding wants list is because price serves as an intuitive gut check over priority and, as long as we see our personal living standards improve, we don't care that we can never fulfil all our wants and we don't bother applying "won't buy" or "item does not exist in real life" tags on our list. (this is an analogy, ok. Please don't try and fight the hypothetical on this, I'm aware our economic wants are significantly more complicated than that). One of the ideas I've been tinkering with is to treat issue tracking less like a todo list and more like a storefront. A todo list with ever increasing entries is stressful experience, a storefront with expanding inventory is not. Items would have a base cost associated with it and a "shipping cost" so that 2 day shipping costs more than USPS ground (aka: Whenever we can get to it). External clients get to create items on the storefront, set the price and the shipping costs using some kind of artificial currency and engineering gets to figure out which orders to fulfil and in what order to maximize revenue. Of course, to paraphrase jwz, "You have a problem and you think "Oh, I know, I'll solve it with an artificial currency". Now you have two problems". Still, I think it's worthwhile getting back to the foundations and think of what an issue tracker does in the context of software development and whether there's a better thing that could serve the same purpose.

sandal 11y ago
You make a lot of good points, and I agree with most of them. The goal of the essay though is not to suggest that tracking issue count is a useful metric. Instead, what I'm suggesting is that if you see lots of stuff going wrong in a project (things that are clearly costing time and money, angering customers, etc.) and then you look at whatever issue tracker is in place and you see a pattern like this, it's a sign of a broken triage and prioritization process. It's so common for this to be happening that I've seen this in many different projects, and I think you're spot on when you say it's because an issue tracker wants to be so many things at once, and it rarely closely tracks value. But in crisis situations, people on the front side of the business feel like they're "doing something" to help customers and users by filing tickets and then continuing to ask for status updates for them, to fight for their inclusion in prioritization meetings, etc. Because this does not actually help anything, it actually ends up hurting things. The tracker ends up as a mediator that obscures or limits communication about the real issues, and without a change, that can be disastrous in a troubled organization. So... the point of the graph is more of a quick way to confirm that triage/prioritization is being done wrong, so that you can make a decision on how to fix that. And that's what I'll cover in the followup essay. :-)
- shalmanese 11y ago
  I think we're in agreement about the important issues. It just saddens me that the proposed short term fixes all seem to involve additional process and overhead to deal with pathologies brought on by the issue tracker. Whenever I spot a long running bugzilla thread with all of the "Bug X was marked a duplicate of this bug", I imagine just how many manhours have been sacrificed to appease the issue tracker gods because our tools aren't flexible enough to adapt to us so we end up adapting to our tools.
  - sandal 11y ago
    My solution involves cutting that overhead, not adding to it. Most of the proposed fixes are ones I agree with in spirit, but implemented a little bit differently in practice.
LoSboccacc 11y ago
I went total opposite direction. My team is small and focused on a single product so ymmv: real life bugs and 'papercuts', which are high number low duration tasks directly influencing our software adoption go in the tracker to avoid losing them on the road. New tasks, requirements, features and nice to have go, on a macro level, into a wiki page, where all the political improductive infighting takes place. I asked the shareholders to keep a ordered list, since giving them priorities is a sure way to have everything escalated to critical. A couple week before every iteratiom three/four of the top macro features go to UX design and whatever emerges is sent to built. So far it's working well, it isolates the team nicely from the madness above, while also allowing a single place where a roadmap exists, even if in a fluid ever changing state. Macro task don't get into the traker because they're hardly ever finished and just pollute it; we do as much in a iteration of the feature x as needed to be useful then throw the rest back on top of the queue as x part 2 or x enhanchement.
- shalmanese 11y ago
  Issue trackers work perfectly well in the small and there are plenty of historical examples of successful issue tracker implementation among small, tightly scoped products with good communication. The problem is, as it scales, you have to start making tradeoffs between the different desires everyone has over what an issue tracker should be. Does every issue have to go into the issue tracker? If I spot a typo on the about page, do I have to file an issue or can I just IM Lisa and she can apply the fix? Does the issue tracker have to reflect the ground truth at all times? If a defect was assigned to Bob and Bob and Lisa have lunch in the cafeteria and Lisa figures out she can fix the issue better, does Bob then have to go back to his desk and reassign the issue to Lisa? Is the issue tracker for employees only or for management as well? For product companies, tracking time is generally unimportant but consulting companies generally require each hour needs to be billed to a particular client. Tying together the issue tracker with the time tracker seems like an initially appealing solution to this problem but now introduces a whole new world of pain. Is the issue tracker used for prioritization or is a separate system used? Both have pros and cons. Generally, when you hear people's gripes around issue trackers, it's not around the particular software but the policies surrounding it. But the reason why you hear so many complaints about the policies is because the intrinsic structure around how issue trackers are built actively encourage bad policy because of how many conflicting goals it purports to solve.

sandal 11y ago

You make a lot of good points, and I agree with most of them. The goal of the essay though is not to suggest that tracking issue count is a useful metric. Instead, what I'm suggesting is that if you see lots of stuff going wrong in a project (things that are clearly costing time and money, angering customers, etc.) and then you look at whatever issue tracker is in place and you see a pattern like this, it's a sign of a broken triage and prioritization process. It's so common for this to be happening that I've seen this in many different projects, and I think you're spot on when you say it's because an issue tracker wants to be so many things at once, and it rarely closely tracks value. But in crisis situations, people on the front side of the business feel like they're "doing something" to help customers and users by filing tickets and then continuing to ask for status updates for them, to fight for their inclusion in prioritization meetings, etc. Because this does not actually help anything, it actually ends up hurting things. The tracker ends up as a mediator that obscures or limits communication about the real issues, and without a change, that can be disastrous in a troubled organization. So... the point of the graph is more of a quick way to confirm that triage/prioritization is being done wrong, so that you can make a decision on how to fix that. And that's what I'll cover in the followup essay. :-)

shalmanese 11y ago
I think we're in agreement about the important issues. It just saddens me that the proposed short term fixes all seem to involve additional process and overhead to deal with pathologies brought on by the issue tracker. Whenever I spot a long running bugzilla thread with all of the "Bug X was marked a duplicate of this bug", I imagine just how many manhours have been sacrificed to appease the issue tracker gods because our tools aren't flexible enough to adapt to us so we end up adapting to our tools.
- sandal 11y ago
  My solution involves cutting that overhead, not adding to it. Most of the proposed fixes are ones I agree with in spirit, but implemented a little bit differently in practice.

LoSboccacc 11y ago

I went total opposite direction. My team is small and focused on a single product so ymmv: real life bugs and 'papercuts', which are high number low duration tasks directly influencing our software adoption go in the tracker to avoid losing them on the road. New tasks, requirements, features and nice to have go, on a macro level, into a wiki page, where all the political improductive infighting takes place. I asked the shareholders to keep a ordered list, since giving them priorities is a sure way to have everything escalated to critical. A couple week before every iteratiom three/four of the top macro features go to UX design and whatever emerges is sent to built. So far it's working well, it isolates the team nicely from the madness above, while also allowing a single place where a roadmap exists, even if in a fluid ever changing state. Macro task don't get into the traker because they're hardly ever finished and just pollute it; we do as much in a iteration of the feature x as needed to be useful then throw the rest back on top of the queue as x part 2 or x enhanchement.

shalmanese 11y ago
Issue trackers work perfectly well in the small and there are plenty of historical examples of successful issue tracker implementation among small, tightly scoped products with good communication. The problem is, as it scales, you have to start making tradeoffs between the different desires everyone has over what an issue tracker should be. Does every issue have to go into the issue tracker? If I spot a typo on the about page, do I have to file an issue or can I just IM Lisa and she can apply the fix? Does the issue tracker have to reflect the ground truth at all times? If a defect was assigned to Bob and Bob and Lisa have lunch in the cafeteria and Lisa figures out she can fix the issue better, does Bob then have to go back to his desk and reassign the issue to Lisa? Is the issue tracker for employees only or for management as well? For product companies, tracking time is generally unimportant but consulting companies generally require each hour needs to be billed to a particular client. Tying together the issue tracker with the time tracker seems like an initially appealing solution to this problem but now introduces a whole new world of pain. Is the issue tracker used for prioritization or is a separate system used? Both have pros and cons. Generally, when you hear people's gripes around issue trackers, it's not around the particular software but the policies surrounding it. But the reason why you hear so many complaints about the policies is because the intrinsic structure around how issue trackers are built actively encourage bad policy because of how many conflicting goals it purports to solve.