Almost every day one of my teammates will come to me with a "bug" or problem they discovered and want to know if we should fix it as part of the next deployment, or wait for the QA department (whom we jokingly refer to as the bug hunting team) to do some more thorough testing and research. Each time this happens, I invariably ask them the same two questions:
- What's the problem?
- Why should we care?
These two questions have served me faithfully for a long time. They encapsulate everything I need to know before I can make a decision as to whether or not the discovered bug needs to be fixed right now.
What's the Problem?
Seems like a simple enough question, right? What's the issue here? This first question's value is easy to pin down: we have to know what the problem is before we can hope to fix it.
There's a trick to the question, though. The trick is that most of the time I already know (or can guess) the answer and just want my teammate to explain it out loud as a way of working through the problem for him/her self. I find that reasoning through problems out loud helps to work out what possible solutions exist for that particular problem (I've heard this called rubber-duck debugging). In my experience, it often helps the person doing the talking reach a solution or, at least, eliminate some solutions that won't actually fix the problem.
Mostly, I ask the question and then just listen, because often they'll work out the problem themselves. But even if they have a solution, I still need to be convinced that I should even care about this bug, and that's where the second question comes into play.
Why Should We Care?
The second question serves a whole host of wonderful purposes at the same time, because it is very general. By asking this question, I'm implicitly giving a demand: Make me care enough to devote time and resources to fixing this bug. If they can't find a reason to make me care, we delay the bug (or possibly don't fix it at all).
Oftentimes I, as the "lead" developer, don't get presented with bugs like these unless the person who found it already has a workable solution, at least in theory. If that solution is feasible, relatively easy, and has a large impact, well then we just might end up doing that. Most of the time, though, the decision is not that simple.
For example, say a junior programmer on my team finds a "bug" that affects an extremely small number of users. This particular "bug" is in a system that has been deployed for two years, and in that timeframe we've received no complaints and no issues regarding that particular section of the code. In this case, I may not care enough to fix the bug; it would take too much time for too little benefit.
For another example, say a teammate finds a bug in a feature that is about to be deployed. This feature will only be used by a few persons, but will probably impact their ability to do their job should we let the bug get past us. In this situation, I'd be hard-pressed to let this bug slide, since the impact it is going to have is measurable and not trivially small.
Much of the time, the decision falls in between those two extremes. Perhaps we know what the bug is, but don't know enough to be able to determine what the impact of fixing it (or of leaving it alone) would be. Perhaps we think there's a bug, but we can't prove it without devoting extra time to pinning it down. There's a lot of possibilities.
The point of all this is that if we're going to divert time and resources that we could use to actually deliver a product to fixing a bug instead, it had better be worth fixing. We all have a limited amount of time for one reason or another, and so finding a justification for spending some of our time on a bug is why I need this two-step process. The decision to divert resources isn't often a simple one, and these two questions help me narrow down what actions me and my group can take.
Next time you find yourself presented with a bug that might need to be fixed, or maybe you found a bug that someone else has to make the call on, try asking: "What's the problem, and why should I care?"
