Fixing the Perception of Bugs
More bugs, and bug reports, are good. No really, at least that's what Karl Fogel says in trying to squash the idea that bugs are "technical debt" that developers must repay.
Fogel, who works for Canonical on the Launchpad platform, says that it's a fallacy that growths in bug reports is bad. On the contrary, more bug reports mean good news because it means more users are using the project. If you've participated in a growing project, it's not unusual to see alarm at the growing number of bug reports and the inability to address them all. Soon, developers start talking about focusing on bugs and not features. Fogel says that's also "technical debt:"
A healthy project is in a constant state of triage between bugs and feature development, and the bugs must not always win. A project can't let the bug database determine how developers spend all their time, any more than an individual person can let their email inbox determine how they spend all their time. If you're not expecting to close all the bugs, and you want to acquire more users (so you can get more bugs), then you have to both fix bugs and add or improve features, and you have to be fundamentally comfortable with an ever-growing database of bug reports.
Think of it this way: every unimplemented feature or improvement is also a bug, in a broader sense, whether it’s filed as such in the tracker or not. It is an absence of something that should be present in the software. So if you manage to close out all your bugs, but you ship without that improvement, then you're still shipping with a bug, you're just calling it something else (or not calling it by any name at all). Shipping with no bugs at all is therefore impossible for any active project. It might be theoretically possible for some extremely narrowly-scoped project, but by definition such a project would not be "active": it would achieve its goal and then remain static and perfect forever. Chances are this does not describe most projects you work on.
Fogel suggests that core developers will naturally spend more time on bugs as a project matures, but the percentage has to level off or reach 100% of the time working on the project. Since that's unreasonable, Fogel says that developers should just pick a percentage of time and spend that working on bugs.
Seems like good advice for developers, and also good for users and contributors outside the development team to keep in mind. Projects that move quickly and develop new features quickly will by their nature wind up with more bugs in the hopper. This isn't worth getting too angsty about because it isn't necessarily a sign that the project is losing quality — it's a sign that a lot more people are looking at it and finding bugs that would have gone unnoticed if the user base stayed static.
It's tempting, but usually inaccurate, to look at projects by bug count alone. Serious bugs that persist for a long time are more worrying than a long, and growing, list of trivial bugs that may not be addressed in the name of shipping some newer features that benefit the larger user base.
Fogel also warns against discouraging bug reports as a way to control the bug count. "Far better to know how many bugs are coming in, how fast, and of what nature, so you can understand how your user base is growing and develop appropriately scaled statistical mechanisms for handling the problems they encounter. Thinking of that information as a debt, rather than a resource, can cripple your project."