For example, if bugs get identified quickly and fixes mailed quickly, but the fixes sit in code review for a long time, maybe it's time to lean on your code reviewers a bit more. If 50% of your bugs are CSS regressions, maybe it's time to invest in a CSS-testing framework. If most of your bugs are crashes caused by memory corruption, you need to straighten out object ownership in your C++.
These kind of overall patterns are very hard to discern when you're considering one bug at a time, yet fixing the root cause of them can lead to big productivity gains.
They can come back and bite you. What may seem innocuous in one system now may end up being a huge roadblock later on down the line when you want to extend/modify/update said system with new features. While I understand that some bugs are simply too minor and the edge cases simply too rare to bother fixing, it's still a good idea to track them.
This also makes certain that they aren't brought up again as a new bug six months down the line - you can point to the tracking software and say, "Yes. We know about it, and it's not worth fixing."
It may, that's true. But it's very unlikely, and what seems like a huge roadblock now in terms of missing functionality is much more likely to be a huge roadblock later as well.
I think the point of this system is not to say that low-priority bugs are pointless - just that there's almost always going to be something higher priority, so they're not worth the tracking overhead.
I've seen a lot of time wasted trying to anticipate what might break later on and bullet-proofing that, when the bullet-proofing simply breaks in new and unforeseeable ways when you actually do try to extend it.
As for running across the same bug six months later - at that point, you probably should reevaluate and decide again whether you want to fix it. The "WONTFIX" designation was made on the basis of information that's now 6 months out of date - the fact that the bug has come up to bite you again is perhaps a good reason why now it should be fixed.
What if it's both high-priority and hard? Like you find out that a fundamental part of how your product works causes data to be miscalculated in a certain scenario, and rewriting it while maintaining backward compatibility is a multi-week task? During which you will get more high-priority bugs...
This article sounds like a fantastic sentiment, but even a small project of a few hundred thousand lines will completely fall over as soon as it's released into the wild. And if you had a medium-sized project you wouldn't even make it past the point where internal testing is doing large scenario evaluation.
That said, if it works for your team, go for it. Never throw in more process than you need, but don't assume that what works for small teams scales. Unless you're trying to sell a book or consulting services, of course :-)
Perhaps it's a matter of terminology, if something is going to take a significant block of time and have multiple people working on it then you need some way of planning and tracking progress, your bug tracker may support project planning as well (JIRA perhaps), but used a pure bug tracker will not be as effective in fixing the problem.
"That said, if it works for your team, go for it. Never throw in more process than you need, but don't assume that what works for small teams scales."
I fully agree with this sentiment, in this case we're talking about a dev team of 6 working in a broader team of 50 developers. So I wouldn't describe it as small, though there again if we were 250 developers then certainly, we'd need more process.
at least that way when the bug re-surfaces, and you discover "its a bigger deal than we thought", you'll know for sure that you've seen it before
But 'Bug Tracking' is used to describe much more than 'Bug Logging'. Bug tracking software packages define themselves and pitch their value based entirely on how they handle that 'everything else'.
Ergo, if you reject the 'everything else' (as the author does), you are rejecting bug tracking software.
In slow weeks (when we have little to do) we pull out the low-pri bugs and fix them - then fire off a personal email to the relevant customer(s). It's helpful in building an ongoing rapport with your clients.
I'd consider that a very worrying sign.
Regardless, slow weeks are always very useful; time to reassess and plan.
Scenario 1: A salesperson or customer advocate reports five bugs found during deployment of application X. Some of the bugs crosses several products, and you have to "pass on" the bug to backend server developer Bob when you find out your code is working as intended. How should you communicate the reported bug and your analysis to Bob? Assign the bug to him in the tracker, and he will get access to the complete bug history - initial report, discussion, reproduction steps, analysis, why-this-isn't-a-problem-with-module-Q-even-though-it-looks-like-it, new comments, screenshots, log files and configuration file attachments from the customer. How will you (and Bob) communicate progress to the salesman? He is CC-ed to each bug in the tracker.
Scenario 2: Your team is responsible for 4 products, which it switches between focusing on every few weeks. When you're hard at work on releasing product A version 3.1, and you spot a nasty and subtle problem with the design of the message queue in the upcoming version 2.3 of product C. Immediately drop development on A? No, you have a deadline to respect and the product C bug isn't affecting anyone yet. Forget about the bug and hope to rediscover it or remember it (and 5 others) in 6 weeks time? That is irresponsible. You put it in the bug tracker, and when product C time comes around, you look at the bug database before starting work.
Or as larsberg says, when your project reaches a certain size and userbase, you will get several hard and timeconsuming bugs at the same time. You can't always fixemrightaway or drop them.
Having this data collection & reporting allows you to identify & trend problem areas that can not be seen looking at a single bug at a time by different people. It also allows you collect similar/overlapping areas of work to strategically manage your resources and productivity - saving you time and money.
Maybe the case is that the article comes from a company that's just too small to realize the benefits of planning.
Another idea is to simply try find out where a bug might be and add a TODO comment to the file/class. This way, if someone changes that class later they can keep the issue in mind.
Also, what everyone else said :)
Ideal situation is where you don't need a bug tracker.