5 ms·

Joel’s 100% correct about limiting the size of the backlog. It doesn’t matter whether you’re using a kanban system, SRUM, a bug database, Github issues, whateve

Joel’s 100% correct about limiting the size of the backlog. It doesn’t matter whether you’re using a kanban system, SRUM, a bug database, Github issues, whatever. The team’s attention is a finite resource, and stuffing items in there wastes it. Limiting the size forces you to throw items out as you go along, and each one of these “We’re never going to do this” decision helps sharpen the design and prevent over-architecture.

loceng 14y ago
Yup. It forces you to prioritize, and if you don't have that constraint you will be forever overloaded and overwhelmed; Things that no longer have the same value or relevance may linger in your mind through the reminders of scanning the backlog + psychologically, having a mountain of things to do feels like a mountain of things to do - there's no need to remind yourself of those, as if they are important enough you will remember them, re-visit them, they will re-surface.
jerf 14y ago
I've had some personal success with acquiring a bit of a Zen attitude about bugs in the bug database stacking up, and just letting the good stuff float to the top, but this appears to be a very difficult attitude to cultivate, based on the fact almost nobody else seems to be able to do this. I've sometimes managed a middle ground where we create a state in the bug system for "Yes, acknowledged", which basically means nothing but allows those who get freaked out about 3000 bugs being "open" to make the bugs "not open" while not requiring the mental commitment to "close" the bugs. (Don't tell them it means nothing! Of course in practice you are basically closing the bugs as "won't fix", but don't tell your managers that.) I suppose my metapoint is that there's a lot more psychology going on here than may meet the eye, and there's more than one way to not drown in the bugs of a basically-functional product.
- gojomo 14y ago
  Indeed, I prefer this approach to Joel's. Whether a giant bug list actually wastes any attention is a matter of attitude, terminology, and interface. If the moldy oldy bugs collect mostly out of view, but can be found when needed – for example when a similar bug is reported again, or an overlapping feature is being added – then this 'long tail' of bugs can be an asset rather than an inventory cost. In fact, I would suggest any mental model that relies too much on the 'physical inventory' analogy can't possibly be making optimal use of the possibilities of digital technology. Bits are nearly free, interface is iteratively-malleable, and improving search offers instant only-when-needed access to arbitrarily large backlogs and historic records. I understand that some meticulous personality types can find this approach disturbing – and these are personality types that are especially good software developers in many dimensions. This tension should be resolved with terminology and interface: let each team member see only the backlog that helps them allocate their attention. There are parallels to the deletionist-vs-inclusionist split in wiki/reference communities. Joel is a bug-deletionist. I am a bug-inclusionist.
  - mechanical_fish 14y ago
    Bits are nearly free, interface is iteratively-malleable, and improving search offers instant only-when-needed access to arbitrarily large backlogs… I am very suspicious of this argument, although I freely admit that my instincts are colored by my old company's use of Atlassian Jira. I was generally okay with Jira, at times when the backlog was under control, but if there's an issue tracker that can manage several thousand active entries without reducing you to tears, Jira is not it. Bits are nearly free, but human attention is not. Human attention is even smaller than a physical filing system. Issue-tracker interfaces may in theory be "infinitely malleable" but that's a yak-shaving exercise waiting to happen. Every minute a team spends redesigning or reconfiguring the issue tracker is a minute they aren't spending working on the product. That's Spolsky's point. Search? When there's one issue in the backlog about the color of the toolbar then search will work great. But then the toolbar acquires a "color" palette. And then two years go by, during which people keep bikeshedding aspects of the toolbar. And then one day you'll search for "toolbar + color" and up will come fifty entries. Which you will probably have to read. If you're a talented search jockey you can probably construct a better query to whittle down that SERP page, assuming your issue tracker has a Google-quality search backend, which it probably does not. But constructing fancy searches takes time and thought. And there's a garbage-in-garbage-out problem with search: If your issues aren't written with a sufficient level of detail, precision, care, and choice of terminology (and somehow they never are), your search won't distinguish them well. Reporting bugs well takes a lot of time and care. Writing carefully-described issue descriptions with a standard terminology takes time, even if you're a trained library scientist. And, again: All that time spent refining searches, scanning SERP pages, and writing well-crafted issue descriptions for better searchability is time you're not spending on the product. You can't ship the prose in your issue tracker.
barista 14y ago
I don't know if throwing away is a better mechanism. I feel the throwing away should also include at least some justification of why it was not important as compared to what you already have on your plate. This will help when the same feature request/bug comes back again. Software landscape changes much more frequently these days. A feature that did not make sense a couple of months ago might be much more appealing today. Knowing why it was rejected in the past would help some channel the discussion better when it shows up again. Also it would help recycle the brain cells that were spent on it last time.

loceng 14y ago

Yup. It forces you to prioritize, and if you don't have that constraint you will be forever overloaded and overwhelmed; Things that no longer have the same value or relevance may linger in your mind through the reminders of scanning the backlog + psychologically, having a mountain of things to do feels like a mountain of things to do - there's no need to remind yourself of those, as if they are important enough you will remember them, re-visit them, they will re-surface.

jerf 14y ago

I've had some personal success with acquiring a bit of a Zen attitude about bugs in the bug database stacking up, and just letting the good stuff float to the top, but this appears to be a very difficult attitude to cultivate, based on the fact almost nobody else seems to be able to do this. I've sometimes managed a middle ground where we create a state in the bug system for "Yes, acknowledged", which basically means nothing but allows those who get freaked out about 3000 bugs being "open" to make the bugs "not open" while not requiring the mental commitment to "close" the bugs. (Don't tell them it means nothing! Of course in practice you are basically closing the bugs as "won't fix", but don't tell your managers that.) I suppose my metapoint is that there's a lot more psychology going on here than may meet the eye, and there's more than one way to not drown in the bugs of a basically-functional product.

gojomo 14y ago
Indeed, I prefer this approach to Joel's. Whether a giant bug list actually wastes any attention is a matter of attitude, terminology, and interface. If the moldy oldy bugs collect mostly out of view, but can be found when needed – for example when a similar bug is reported again, or an overlapping feature is being added – then this 'long tail' of bugs can be an asset rather than an inventory cost. In fact, I would suggest any mental model that relies too much on the 'physical inventory' analogy can't possibly be making optimal use of the possibilities of digital technology. Bits are nearly free, interface is iteratively-malleable, and improving search offers instant only-when-needed access to arbitrarily large backlogs and historic records. I understand that some meticulous personality types can find this approach disturbing – and these are personality types that are especially good software developers in many dimensions. This tension should be resolved with terminology and interface: let each team member see only the backlog that helps them allocate their attention. There are parallels to the deletionist-vs-inclusionist split in wiki/reference communities. Joel is a bug-deletionist. I am a bug-inclusionist.
- mechanical_fish 14y ago
  Bits are nearly free, interface is iteratively-malleable, and improving search offers instant only-when-needed access to arbitrarily large backlogs… I am very suspicious of this argument, although I freely admit that my instincts are colored by my old company's use of Atlassian Jira. I was generally okay with Jira, at times when the backlog was under control, but if there's an issue tracker that can manage several thousand active entries without reducing you to tears, Jira is not it. Bits are nearly free, but human attention is not. Human attention is even smaller than a physical filing system. Issue-tracker interfaces may in theory be "infinitely malleable" but that's a yak-shaving exercise waiting to happen. Every minute a team spends redesigning or reconfiguring the issue tracker is a minute they aren't spending working on the product. That's Spolsky's point. Search? When there's one issue in the backlog about the color of the toolbar then search will work great. But then the toolbar acquires a "color" palette. And then two years go by, during which people keep bikeshedding aspects of the toolbar. And then one day you'll search for "toolbar + color" and up will come fifty entries. Which you will probably have to read. If you're a talented search jockey you can probably construct a better query to whittle down that SERP page, assuming your issue tracker has a Google-quality search backend, which it probably does not. But constructing fancy searches takes time and thought. And there's a garbage-in-garbage-out problem with search: If your issues aren't written with a sufficient level of detail, precision, care, and choice of terminology (and somehow they never are), your search won't distinguish them well. Reporting bugs well takes a lot of time and care. Writing carefully-described issue descriptions with a standard terminology takes time, even if you're a trained library scientist. And, again: All that time spent refining searches, scanning SERP pages, and writing well-crafted issue descriptions for better searchability is time you're not spending on the product. You can't ship the prose in your issue tracker.

barista 14y ago

I don't know if throwing away is a better mechanism. I feel the throwing away should also include at least some justification of why it was not important as compared to what you already have on your plate. This will help when the same feature request/bug comes back again. Software landscape changes much more frequently these days. A feature that did not make sense a couple of months ago might be much more appealing today. Knowing why it was rejected in the past would help some channel the discussion better when it shows up again. Also it would help recycle the brain cells that were spent on it last time.