The title is problematic, because the thesis of the article is not that issue trackers are harmful, but that using them for a product development workflow is problematic.
I’m going to call them bug trackers from here on, because I don’t like the name “issue”, which I find an insipid term that’s kinda part of the problem.
Generalising and simplifying (to the point of at least mild inaccuracy), bug trackers are excellent in open source work, but work trackers and planners are more useful in business.
Also a remark of my own: bug and work trackers both have a painful tendency to slowly increase in scope and try to cover each other’s purposes, but poorly. They’re similar, and there’s definitely some overlap, but they’re quite different in how you treat them, most of all in how you maintain them. An automatic stale bot may be reasonable in a work tracker (though it’s not ideal), but has absolutely no place in a bug tracker. (I have various comments on HN up to +76, and one outlier at +283, https://news.ycombinator.com/item?id=27274146, showing that lots of people agree with me in hating stale bots on bug trackers.)
Actually, what am I saying? Not just such trackers, not even just software, but human endeavour in general tends to scope creep and the problems that arise from it.
And yeah, the title was written in a way to be a bit provocative, but also pointing at that many (maybe most) teams use issue trackers for their product development flow.
Trouble with the title for this site is that a very significant fraction of the users will approach it from the open source perspective where bug tracking is what you want. :-)
I might perhaps title it “bug trackers aren’t good for tracking work” or “bug trackers aren’t good for product development workflows”. I like literal and direct (and often verbose!) in my titles.
I’m going to call them bug trackers from here on, because I don’t like the name “issue”, which I find an insipid term that’s kinda part of the problem.
Generalising and simplifying (to the point of at least mild inaccuracy), bug trackers are excellent in open source work, but work trackers and planners are more useful in business.
Also a remark of my own: bug and work trackers both have a painful tendency to slowly increase in scope and try to cover each other’s purposes, but poorly. They’re similar, and there’s definitely some overlap, but they’re quite different in how you treat them, most of all in how you maintain them. An automatic stale bot may be reasonable in a work tracker (though it’s not ideal), but has absolutely no place in a bug tracker. (I have various comments on HN up to +76, and one outlier at +283, https://news.ycombinator.com/item?id=27274146, showing that lots of people agree with me in hating stale bots on bug trackers.)
Actually, what am I saying? Not just such trackers, not even just software, but human endeavour in general tends to scope creep and the problems that arise from it.