Good Enough

  • Article

While I personally believe that every bug is worth fixing, the reality of business often causes the minimum-cost-for-maximum-benefit line to be drawn elsewhere. Heck, even customers often prioritize new features over bug fixes! (Not that this is a choice they should have to make....) Writing bug-free software is hard. There is no end of techniques and methodologies that claim to get you at least part way there. Some actually do make a noticeable difference. They all take time and effort that may not be available to spend.

Given this state of affairs, we are pretty much reduced to shipping software that is merely good enough. The specs are good enough, the design documents are good enough, the test cases are good enough, the code is good enough, the documentation is good enough. (I might go so for, in fact, as to say that test cases can't ever be better than good enough, because for anything more than the most trivial cases the set of potential tests is large enough that it's impossible to cover every one.) Unfortunately, I can't define "good enough" for you because it has a different definition for every application to which it is applied.

Here's an example: I have just recently finished ripping my ginourmous CD collection to WMA Lossless. I was not always as careful as I should have been, plus my rules for formatting certain parts of album and track titles have changed since I started, so I need to go through 13,500+ tracks fixing up metadata. This is way more than I want to do by hand, so I did what any geek would do and wrote a program that searches out and fixes up those tracks that don't meet my current standards.

Some of these rules are complex. Fixing capitalizations for example, is not as simple as upper-casing the first letter of every word and lower-casing everything else. Certain patterns occur frequently enough that I added logic to account for them, but others are rare enough (or weird enough) that it was faster and simpler to fix them by hand. Certainly I could have spent additional time and handled every last case, but I-as-the-sole-customer decided the delay wasn't worth the benefit.

What I ended with was mostly sufficient for me. If I was shipping this to the general public I would have almost certainlyspent the time to robustify the rules. Good Enough for me in this case was very different than Good Enough is for something I give to others.

I don't know any set formula you can use to make this decision, but there are several steps you can take to make it easier:

  • Set quality goals for each feature before you start designing it, let alone coding or testing it. It's a lot easier to define quality bars at the beginning, before you have reams of code and huge amounts of bugs and passionate feelings all around about the necessity of keeping a particular feature or fixing that heinous bug that "no one can ever actually run into".
  • Make clear right from the start the criteria for bugs that must be fixed versus bugs that can be postponed.
  • Prioritize fixing bugs over new work. On my team, developers can't work on new code if they have any high priority bugs assigned to them.

Knowing the minimum level of quality that is acceptable for your situation is vital to deciding what good enough means. Beyond that, you're pretty much on your own!

*** Comments, questions, feedback? Want a fun job on a great team? I need a tester! Send two coding samples and an explanation of why you chose them, and of course your resume, to me at michhu at microsoft dot com. Great coding skills required.