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

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.