Bugs. They’re the bane of your existence, aren’t they? Over the last few years, I’ve finally gotten to a point where I’m happy with how my team is dealing with bugs. We’re spending less time in the bug database and more time fixing bugs.
So I decided to spread the word to help others. Getting control of my bugs needed two key insights:
- Bug prioritization is a waste of time and just creates friction in the bug fixing process. Credit for this insight goes to a former boss @MikeOsier
- Apply basic time management principles to manage your bugs. For every bug you have to ask yourself “What is the next action?”
Let’s see how that works. When we’re done, we will have achieved bug Nerdvana: You will have a clear list of actionable bugs for your team to work on. Our goal is for your team to never have to ask you what should I do next, because the bug process will make it obvious.
Principles of Good Time Management
I’m going to borrow heavily from Getting Things Done which is one of the best books on time management I’ve ever found. GTD, as its followers call it, is a great book, which I won’t try to summarize here. Instead, I’ll go over some of the concepts from the book that directly apply to software engineering.
- Reduce Friction
- Clarity on the Next Action
We’ll start with reducing friction, but the three principles interrelate to a large degree as we’ll see.
In GTD, David Allen talks a lot about reducing friction. For time management, it’s about being organized so you spend the minimum amount of time touching things that aren’t about accomplishing things. But organization isn’t everything, David Allen makes the point early that if you have a to-do item that takes less than 2 minutes to accomplish, its faster to go do that item now than it is to track it as a to-do item.
So lets reduce the amount of time you spend touching bugs. At all the companies I’ve worked, a lot of time was spent grooming the bug collection before work could be started fixing the bugs. This is a perfect example of friction, grooming was work that didn’t generate any results just heat and meetings. So lets get rid of some of the friction.
There Are Only Two Useful Bug Priorities: Holy Shit! and In Order
This is going to be the most controversial part of this article, but having lived through a company that went through this transition, I can tell you, its worth it. You see that “priority” field in your bug database? From now on, you’re going to ignore it. Because its not actually useful, for bugs.
Ok, I hear the but. Yes, you have had bugs you had to fix right now, dammit. That’s reality. That’s why there’s the Holy Shit! priority. But has there ever been a time where you had a Holy Shit bug and you didn’t know the bug number by heart? Where there wasn’t someone coming by every hour to ask if bug 2345 was fixed yet? You don’t need the bug database to tell you that you have a Holy Shit bug. You know it already, and your whole team knows it.
Prioritizing all the other bugs in the database is a waste of time. It is not useful work to look at a bug and decide if it is P2, P3, P4 because at that point, the differences between a P3 and a P4 have little meaning.
Friction can be a sneaky time waster. The bug that inspired my boss to blow up the priority system was a cosmetic spelling mistake that persisted for 3 years in an email to customers, because every 6 months we would notice the misspelling in the email, and downgrade the bug to P3 because we’d already sent that round of emails “so we had time”. There were easily 120 man hours of time wasted over those 3 years in discussing that bug, but it was a 2 minute fix.
It may be hard to believe at first but fixing the rest of your bugs in the order they were found gives you more time to spend fixing them, because you don’t have to spend any time discussing the bug.
Ok, so I still hear a but. That’s because you have bugs in your database that aren’t bugs, they’re features. Because most people put their bugs and their features in the same database, because the line between them can get blurry.
Features Get Prioritized, and That’s a Good Thing
As a software engineer, we want feedback on how things are working, so we can make our products better. It would be great if that feedback was always positive, and if the negative feedback was constructive criticism.
You should be so lucky. More likely, you get a feature that’s masquerading as a bug. That is, you have something that’s negative, but the action to resolve that issue is new work. That’s one reason understanding the next action on a bug is key.
To illustrate with an example:
- Bug: Export Path Dialog is confusing
- Feature: Improve Export Path Dialog
To the bug reporter, the software is broken because its hard to use. But from the point of view of you, the software engineering manager, the next action for this is a feature: “Improve the Export Path Dialog to be less confusing”.
I won’t kid you, the bug/feature decision is about 80% intuition and experience. But here’s a simple process I follow when deciding:
- What’s my next action to resolve this?
- Is the verb in that action something other than fix?
- Does the verb start with re? (Rework, redesign) It’s a feature, stop.
- Does the next action have “new” in the description? It’s a feature stop.
Now here’s a critical step to follow once you’ve classified the “bug” as a feature: Rewrite the description of the bug. This will actually promote clarity in your bug database, your development process, while addressing the reporters concerns.
Now that this bug is a feature, it makes perfect sense to prioritize this feature against the other features you have outstanding. I have no objection to prioritizing features, that’s just how business works. Your team can only do so much. But they have to fix what’s broken.
The Last Word about priority: Candor
There’s a third priority implied by the Holy Shit/In Order system. Priority: No.
Close bugs you’re not going to fix. Own that, and talk to the person who filed the bug. If you follow the rest of the process, you’ll find you’re closing fewer than you think, and the next few steps will help you deal with that. I call this step Candor, because its about being straightforward with your bug customers when you’re not going to fix something.
Clarity on the Next Action
We hinted a little bit about this with the discussion about bugs vs. features, but understanding the next action on a bug is also key to prioritization. Make sure all your bugs are actionable. An actionable bug is a bug that your team can start on fixing today. Without knowing you, I already know that not all bugs in your database are actionable. Non-actionable bugs can’t be started, so will accumulate because to the point where the majority of outstanding bugs can’t actually be worked on.
Most common reasons bugs aren’t actionable:
- Next Action: Other Team The bug depends on some other team to do something first.
- Next Action: Infrastructure You need to build/fix/revamp some infrastructure to fix this bug properly.
- Next Action: Requirements The bug description is so vague, you have no idea what to actually do.
Most bug tracking systems have a mechanism to label or categorize bugs. If you label or categorize this non-actionable bugs, you can easily put them off to the side where you won’t have to groom them again until they’re ready. When you build filters to show your team only the actionable bugs, in time order, it becomes another way to save your team time: They don’t have to read through a bunch of bugs they can’t work on to find one they can.
I’ve given you enough categories to get started, but you can make your own labels. My process for this is pretty simple. As the development manager, I read the bug, and if its not actionable, I label it “nextaction-
Next Action: Infrastructure Is Your Most Important Label
Ok, lets be candid for a second. You know and I know that your codebase isn’t perfect. Even if you had started with a perfect architecture, that was three business pivots ago, and now your architecture isn’t quite a match for the problem set. You’ve been accumulating bugs that really should be fixed by rebuilding some other piece of code inside your system, so its not time to work on those yet.
But then you have to justify rebuilding that code to your boss or project manager, who is pushing you to deliver a grab bag full of features yesterday.
For bugs that depend on others, you’re pushing that bug onto a siding because you’re waiting on someone else. But for bugs that are relating to a piece of infrastructure, you’re waiting on yourself.
The solution is simple in most bug systems. When you label a bug with infrastructure as the next action, also file the bug/feature for that infrastructure, and link the two together. Now your bug database is helping you by making it obvious which pieces of infrastructure need to be worked on first, and you can use the information from the bug database to help you set priorities with your stakeholders.
The cost/benefit for rebuilding that piece of infrastructure is clear: If we rebuild component X, it will resolve N bugs. Your stakeholders will love it.
Hopefully, you’ve gotten the following key takeaways from this article:
- Reduce friction with your bug database by simplifying your priorities. You really only need Holy Shit/FIFO/No. Clarity on the next action helps with this because often bugs are downgraded in priority not because they aren’t important, but because they aren’t actionable yet.
- Clarity on the next action with a bug helps you isolate the actionable bugs from the non-actionable bugs. This further reduces friction by moving things you can’t work on yet to a siding.
- Bugs that need infrastructure as their next action can be used to justify long term improvements in your code.