How to Prioritize Bugs on Your To-Do List
Editorial Note: I originally wrote this post for the NDepend blog. You can check out the original here, at their site. While you’re there, take a look around at NDepend and explore its new tech debt measurement features.
People frequently ask me questions about code quality. People also frequently ask me questions about efficiency and productivity. But it seems we rarely wind up talking about the two together. How can you most efficiently improve quality via the fixing of bugs. Or, more specifically, how should you prioritize the list of bugs that you have?
Let me be clear about something up front. I’m not going to offer you some kind of grand unified scheme of bug prioritization. If I tried, the attempt would come off as utterly quixotic. Because software shops, roles, and offerings vary so widely, I cannot address every possible situation.
Instead, I will offer a few different philosophies of prioritization, leaving the execution mechanics up to you. These should cover most common scenarios that software developers and project managers will encounter.
Maximizing Self Interest
I’ll lead with the scenario probably most common to software developers. Stop me if this sounds familiar. The first interaction point you have with a bug is receiving an email from Jira or TFS or Rally or whatever. From there, you log in, read the details, and check the pre-assigned priority. You check that because of the bug-fixing algorithm imposed on you by management: fix any priority 1 bugs, or, if you have none of those, any priority 2 bugs, and so on down the line.
In this world, bug fixing becomes a matter of looking after your own self interest. Prioritizing your own to do list, consequently, becomes simple. Management and the business have made the important, strategic decisions already and will evaluate you on the basis of quantity of defects fixed. Thus you should prioritize the easiest to fix first, so that you fix as many as possible.
This may sound cynical to you, but I’m fine with that. I have a fundamental distaste for the specialization obsession we have that separates fixing and prioritization. Organizations that freeze technical people out of the strategic discussion of priority reap what they sow. Robbed of the ability to act in the organization’s best interests, developers should act in their own. Of course, I would prefer developers participate in the “how do we act in the company’s best interests” discussions.