Start with a Good Codebase
A good codebase is the one in which bugs are easier and quicker to find. In my opinion, the most appropriate metric to measure the goodness of a codebase is the Average Bug Age (ABA), which is also known as bug cycle time. The ABA of open bugs is the key to determine if a codebase is debt-free and of high quality. With a good codebase, the following will be true:
- Since it’s easy and quick to fix bugs, the majority of bugs have already been fixed with the help of bug management tools. This results in a high-quality product.
- When bug fixing becomes fast and easier, so does adding new features. This increases the overall productivity of the team.
Now that we know what a good codebase is made of, let’s explore the actual bug fixing.
Return Bugs to Their Creators
Real-time bug fixing is important. In The Scrum Field Guide, fix high and mid-priority bugs in real-time but put low-priority ones on the product backlog. Fixing all bugs (even the low-priority ones) using bug management tools in real-time is also an effective strategy. But this approach has a depth to it. To do so, your team needs to have a rule where the person who writes the buggy code needs to fix it before doing anything else. This is how the flow works:
The team member finds the bug and the originator who wrote that bit of code. The discoverer (who found the bug) approaches the originator and asks him/her to fix the bug together. The originator immediately stops his ongoing work and shifts his/her focus to fixing the bug with the discoverer. While teams hate this rule, the benefits far outweigh any negative reactions. The biggest advantage is that the bug-prone members tend to spend a lot of their time fixing old bugs instead of writing new code. As a result, the best coders write the vast majority of the codebase. There are three important side effects of this rule:
- It limits the damage a team member can do
- The team members who write clean and effective code are rewarded. These members are usually the ones who have figured out how to do TDD and when and how to refactor. As a reward, they are freed up to write even more code.
This provides the team members with the incentive to learn to write better code. As a result, the team productivity increases and so does the stability and quality of the codebase.
Fix the Low-Priority Bugs in Real-Time or Dump Them
Development teams have a tricky decision to make: Should we put bugs on product backlog or not? In my opinion, you shouldn’t. Just fix them or mark them as won’t fix. This approach will lower your average bug and improve the code quality and allow you to deliver faster.
