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.
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.