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 <i>process</i> that you want to fix.<p>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++.<p>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:<p>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.<p>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."
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."<p>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...<p>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.<p>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 :-)
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.<p>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
It's good to track low priority bugs; and specifically the customer they affect.<p>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.
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. :)<p>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.<p>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 <i>hope</i> 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.<p>Or as larsberg says, when your project reaches a certain size and userbase, you <i>will</i> get several hard and timeconsuming bugs at the same time. You can't always fixemrightaway or drop them.
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.
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.<p>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.<p>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.<p>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.<p>Also, what everyone else said :)