Tracking and Fixing Bugs In Software Projects
Out Of Date Warning
Languages change. Perspectives are different. Ideas move on. This article was published on January 4, 2010 which is more than two years ago. It may be out of date. You should verify that technical information in this article is still current before relying upon it for your own purposes.
In software development, it’s crucial to track bugs and new features, and to be able to know exactly where a project is at any given moment. Bug tracking is crucial tot his goal; it allows a project manager to know what has been finished and what still must be done, as well as to outline to each developer their goals and responsibilities.
Most developers agree on the importance of bug tracking. Here are five tips I use when utilizing bug tracking.
Institute bug tracking for the development team, even if management won’t.
Occasionally I’ve been on a team where the management team doesn’t understand the point of bug tracking. However, upper management need not understand in order for the tracking to be effective. Bug tracking is, for the most part, a developer’s tool, to track errors, add features, and improve the development process.
There are lots of open source bug tracking packages that are free and easy to use. They can be set up on any server, and usually don’t require special setups.
Create bugs if other teams won’t.
It’s possible that other teams may also not understand the purpose or value of bug tracking, and will refuse to file bugs in the system. This is especially prevalent if the upper management team doesn’t support bug tracking.
It’s tempting to struggle against other teams to convince them to use the bug tracking system. This will almost always fail. Instead, it’s often easier to institute a policy amongst the development team to convert service requests into tickets yourself. As a team you may also consider filing the tickets with the requester as the person watching the ticket. After a few closed tickets, other teams may see the value and begin filing tickets.
Track every bug, big and small.
There are two reasons why you want to track each and every issue in a bug tracking database: first, because it’s impossible to hold all the information in your head, and second, because it creates some very good documentation of the project over time.
Joel Spolsky does a fabulous job explaining how remembering bugs gets more difficult as time goes on. However, the value of the documentation created by bug tracking is often overlooked. When bugs are filed, and fixed, and time goes on, it’s easy to generate statistics on who creates, who fixes, and what fixes are applied in the code base. New bugs can be linked to old bugs (to see regressions), and all the problems that have ever been solved are in one place.
For this, it is crucial that whatever bug system you use has awesome search capabilities. It’s also important that developers write detailed notes on their solutions, or link to repository commits so that other developers can see the changes made.
Track bugs and features together.
While it’s known as a “bug database” it should really be an “issue database” because it should record everything, bugs and features together. Why? Because it makes it easier to know what work is on the table before getting started on a particular project.
Having both bugs and features in the same place means that the project manager as well as the developers can see the tasks on hand, as well as determine what should be pushed into the next release. Often times when considering a new release, project managers only consider new features, because they don’t see the amount of work that must be done to fix the bugs. Having them together will help ensure that this doesn’t happen.
Fix old bugs before starting on new features.
The link to Joel’s post above outlines some of the benefits of starting on bugs before working on new features. I won’t rehash his points; what I will add is this: fixing old bugs first is crucial because developers hate doing it. Developers like working on new code. Developers hate going back and working on old code that they’ve already written, or that other people have written. By forcing developers to fix outstanding bugs before they work on the “latest and greatest” new features means that the bugs will actually get fixed, rather than being pushed off and pushed off until they’re all that’s left before shipping the product.