Sitting there at our desks in the morning staring at the list of defects confronting us can be overwhelming.
Scanning through them, we often come to realize that the highest priority defects will be both tricky and time consuming to fix. We realize that most of our day will be spent on just a small number of them, which means that our list will be nearly as big tomorrow as it was today. And of course, depending upon tester activity, we could end the day with a much longer list than which we began.
Like in the Red Queen’s Race, we run as hard as we can and end our day no closer to finishing.
The situation can be improved.
Dave Ramesey, a popular financial advisor who helps people get out of debt, suggests using the debt snowball approach for overcoming debt. The essence of this strategy is to pay off all of our debts by beginning with the smallest one first, and then progressively working our way toward the largest. By taking this approach we build the will and the psychological momentum needed to help us payoff our biggest debts
We can apply this strategy to fixing software defects.
The obvious way to apply this strategy is literally, and it does not work. That is, no one is going to be happy if we just re-prioritize our entire list so that the easiest to fix defects have the highest priority.
So what we will do instead is partially re-prioritize our list in order to “prime the pump”. That is, by picking one or two quick-to-fix defects at the beginning of our day, or even in the middle of the day between big jobs, and then fixing them immediately, we generate some momentum for taking on our bigger challenges.
In addition, I have found that those who reported the lesser priority, but easily fixable defects are always happy to see their issues resolved sooner than expected. What’s more, individuals who are waiting on the large problems to be fixed are typically not bothered by the relatively minor digression. So on top of helping us be more productive, this technique also engenders good will amongst our colleagues.
Another effect of this “defect snowball” method is that the application of it helps to keep our defect queue clear of small problems, and thus prevents them from adding up and becoming a big problem later.
Now of course some care must be taken when choosing the “easy” defects to fix. To avoid jumping head first into an unexpected big problem, we really want to limit ourselves to choosing ones that are obviously low effort. Defects that are almost always low effort are the ones associated with the quality of error messages or misspellings. Sometimes we can also find “quick fix” defects that are in the same software element as one of our big defects, and which if attacked together saves us a context shift.
However, regardless of the particulars, sound judgement and knowledge of the details on the ground are definitely required. Developing an intuition about when to abandon something previously thought “easy” is also a good skill to hone.