A Winning Technique to Make You a Powerful Debugger

Don’t we all have this feeling at some point?

Very rarely will you work on a software project that has only one or two bugs. Sure, you may get away with such a low rate on some of your beginner programming exercises, but in the real world of software development, that’s practically an unknown luxury.

How do you keep track of all the bugs you encounter? How will you handle that giant list of problems waiting to be solved? On a professional development team, you will probably have some sort of bug tracking software. In the “working world” you’ll probably see the terms “defect management” and “issue management” as well, because sometimes you might have an issue or feature that needs to be changed or addressed, but isn’t necessarily a bug. Some examples of popular trackers include Jira, Rational ClearQuest, and HP Quality Center. These software tools are often very expensive, and designed for larger companies and enterprise solutions, so they probably aren’t going to fit your budget as an individual developer. Luckily, there are also some good free and/or open-source tools available, such as BugZilla, Mantis, and Trac.

Create Your Own Bug Tracker

Another free alternative, especially if you’re working alone, is to create a bug tracking spreadsheet, using Microsoft Excel, Open Office Calc, or any other spreadsheet application. You can check out a sample template (a modified example from an actual game I made), available in my debugging guide here, or you can make your own from scratch. Here’s an explanation of the columns you’ll want to set up:

• Bug/Issue: A description of the bug or issue. This part can be a short, high-level overview, maybe a sentence or two, that people can quickly view and understand. You can give further details in the Notes column. Another option is to create some sort of bug ID number or tag system, and you can use this column for that ID, or create an additional ID column.
• Notes: More detailed information about the issue. Feel free to add to this column as needed. It’s a good way to keep track of your progress as you learn more about the problem. You might also link to additional documents or files in this column.
• Status: An indicator of how far along you are in fixing the bug. You can make your own statuses, but I like to create a fixed set of status options and update this column as the bug transitions to a new state. Note that sometimes you might have to revisit a status. For example, if you had a bug that you moved to testing phase, but then found out that the problem wasn’t solved, you might move it back from testing to repair phase again. Here are some status options that I like to use, and you can modify and add to them as you see fit:

1. Not Started: The issue is new and no one has started working on it yet.
2. In Progress: Someone has started working on the issue. If you’re working in a team, you might also want a column that says who is working on the issue. To help promote productivity and actually get things done, try to set a limit for how many items you have in this column at any one time. For example, maybe each person can only have 5 items in progress, and s/he must not start any new tasks if the limit is reached.
3. Fixed/Needs Verification: You can use this status when you believe that you have fixed an issue, but need to fully test it first, before marking it as completed and solved.
4. Completed and Verified/Done: When you finish working on an issue and verify that it is fixed and meets all requirements, move it to this status. Again, note that because you can never truly verify the absence of a bug, there’s always a possibility that you’ll have to move a bug of this status back to “In Progress.” In my debugging career, for example, I’ve worked on bugs that my team assumed were resolved, but kept coming back to us.

• Priority: Prioritize your bugs based on how important it is to fix each of them. You can use any system you want (for example, you can use a scale from 1–5, with 1 being the most important, and 5 being the least). It’s also a good idea to note somewhere in the column heading what your system is, especially if other people are going to be sharing the tracking sheet. Priorities are important because if you are running out of time or resources, you can figure out which issues should receive most of your attention.
• Impact/Severity: A measure of how significant the issue is. Is it a minor bug that really doesn’t have much effect, and that the user can easily ignore, or is it a “show-stopper” that will make your program practically unusable? Does it have a serious impact on a critical feature, or is it just a minor cosmetic issue? Again, as with the priority, you can choose a numerical or other system to use.
• Estimated Level of Effort (LoE): An estimate of how much time you believe it will take to fix the bug. Don’t worry if you have trouble making accurate estimates. That’s an important skill that you can develop over time. Even project management specialists and professional developers often don’t get it right; one of the biggest problems in software development is not meeting deadlines because the team didn’t allocate enough time. Use this tool as an opportunity to start improving your estimation skills, and you’ll stand out from the rest of the developers! It’s also a good idea to add in some extra time on top of your base estimate, to act as a buffer in case things don’t go as planned (and that’s pretty much guaranteed to happen).
• Actual Level of Effort (LoE): The actual amount of time you spent fixing the bug. It’s good to keep track of this figure, because as you get more experience, you’ll hopefully see that your estimates are more closely matching the actual times.
• Date Added: The date when the issue was added to the tracker. This column can help you keep track of how long an item has been sitting in the queue.
• Date Due: If applicable, the deadline for when this bug needs to be addressed.
• Date Started: The date you started work on this issue. This column, as well as the “Date Ended” column, are particularly helpful if you ever want to keep track of how you’ve been spending your time during a given day or time period. If you regularly provide status reports to a team lead, for example, these columns help you accurately show what you’ve been working on.
• Date Ended: Once you’ve marked a bug as completed, you can note the closing date here.

How This Tracker Helps You

This simple, yet effective system can help your debugging skills and process in several ways.

• Saves you valuable time by helping you prioritize the most important bugs you should be working on.
• Keeps your notes and supporting information in one place.
• Lets you see at a glance the status of each issue, and who is working on it, if you are working in a team.
• Provides a record of how you’ve been spending your resources and working hours.
• Helps you become better at estimating how long it takes you to fix a bug.

I’ve used this tracking system myself, with great results. I also notice a significant difference in productivity when I don’t follow the system. You can modify this system not just for bugs, but also for tracking regular tasks in your project, even non-programming items. Give it a try!

Build Your Debugging Skills

Are you looking for more help in becoming a better debugger? I have a new guide, The Confident Programmer Debugging Guide, available. This guide includes:

• A real-life example from a major project I worked on, complete with lessons and guidelines.
• Tips on how to stay calm and maintain your sanity when you are frustrated and overwhelmed by your bug list.
• Suggestions on how to research and find information on those pesky error messages.
• A sample bug tracker tool to help you stay organized.
• A debugging checklist to help you figure out the next step.
• A guided debugging exercise, complete with Java code and explanation, and suitable for beginners.

If you find it helpful, or have any questions or comments, please feel free to contact me, or follow me on Twitter or Facebook for more resources and information on the games I’m working on.