I'm a big fan of this approach, but I find that bugtracking is really useful when you want to look back on the project and data-mine to identify problems with your process that you want to fix.
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.
There's a major problem with completely ignoring and not tracking ignored bugs:
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."
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
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.
Then you fix them later, when it becomes a roadblock. At that point, you'll have much more information about why it's a roadblock and how you should change things so that further development proceeds smoothly. And many bugs may never become roadblocks at all (or may be obsoleted by other changes), so you save all the development effort of fixing things speculatively.
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.
This ignores a critical use of bug tracking - communication. This approach might work in a small local team, but falls apart in a bigger organization or in a distributed environment. Bug tracking software is one place to store information about the bug that multiple people can comment on. The person discovering the bug might not be a developer, and often not. The person testing the bug shouldn't be the developer; QA is doing it. If the fix involves several people and they need to add input, they can add in their comments in the bug tracking system. Cvs/Svn/Git can tie with the bug tracking ticket to create a reverse lookup. There are so many benefits to have a bug tracking system.
"Hopefully such occurrences are rare and can be considered a special case."
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 :-)
"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..."
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.
I'm not sure how much team size is relevant here. You're still creating project history through a series of discussions and decisions, things that a bug tracker can record quite well if used properly. Every team also has turnover. Having your project's history recorded in written form can be invaluable for new (and old) developers to research why something was done a certain way, and not have to rely on memory and hearsay to do it.
It's a good strategy when you're doing small, quick, low impact releases. When you have to coordinate with other areas of the company about when, and what to release, or when the software becomes so large that there's a new bug every day, then you need to keep a detailed track of the bugs.
i don't understand what this has to do with bug tracking software. you can realize the same thing by placing all bugs in the tracker, and still ignoring low-importance bugs.
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
I can definitely see an argument for logging; particularly as relates to project and developer metrics.
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.
It's good to track low priority bugs; and specifically the customer they affect.
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.
A real benefit I have found in not tracking bugs is that the constraint makes you much less cavalier about introducing complexity in the first place, which is totally a good thing.
It (obviously) works fine for small to medium projects, but I believe the bug tracker-free approach doesn't scale at all. I don't know if the author thinks it does or not, I just want to point it out to prevent people from getting ideas. :)
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.
Assuming you have more work than resources (which is what one should plan for) I would find it hard to sacrifice the 'strategy' aspect of bug tracking systems. A good bug tracking system allows you to balance quick/low-overhead logging with an ability to create categorical data points that let you analyze your work & workload.
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.
I add low-importance bugs that can be done quickly to a "quick" list. If I have some time to spare, I check that list and knock off a couple.
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.
I often find bugs when I'm too bleary eyed to care about fixing them. If I just go to bed at that time, I'll have forgotten about it in the morning. Instead, filing a 2 line bug report serves as a good enough reminder for when I wake up.
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.