Tuesday, February 26, 2008

"It's Hard" Sometimes Means More Than "It's Hard"

I sat down this morning to write another diatribe against the "it's hard" school of bug closing.* Then I took a deeper look at some of the bugs that trigger that reaction.

Sometimes "it's hard" is shorthand for "we don't get a lot for all this effort".

There are legitimate times to say that a bug is hard to close, or a lot of work to close, and that you don't get much for all that work. For example:
  • You show space utilization to the hundredths of a MB. For a lot more work, you could show it to the thousandths of a MB. Your customers typically write 100GB plus of data to the system. It's not really worth that extra significant figure.
  • You can cause a 1% increase in the performance of your system... if you take the team into isolation for a month to get it done. The only customer complaining about performance is that guy who won't be happy no matter what, and is only worth 0.02% of your annual revenue.
  • Your app allows users to name their modules. There's a bug that the name can't contain an umlaut. None of the rest of your app is globalized. Fixing it in that one spot won't really make your app work in countries where umlauts are in common use.
The more appropriate way to put "it's hard" is "the ROI of making this change is low, so let's not do it". Typically, bugs that fall into this category are those that:
  • Make small performance improvements when performance isn't a problem.
  • Are only a small portion of the total problem and won't help fix the overarching weakness.
  • Don't matter to enough of your customers (or potential customers) to be worth the cost of fixing.
So next time I hear it's hard, I'm going to look hard enough to see if it's whining or if it's really that fixing the bug ain't worth much.

* No, no reason in particular, all you Permabit readers - ya'll are wonderful as usual.

No comments:

Post a Comment