For my last blog for this course instead of taking one
particular course subject, summarizing it, and theorizing about what actual
implementations may look like – I’d like to look at the whole course and do the
same. More specifically, I would like to cover how bugs or defects are actually
addressed, or not, in Software Development and Testing. To do this I have found
some interesting blog posts which argue that 100% of bugs may be able to be
fixed, but shouldn’t be. Instead, one should focus on serving the vast majority
of users under expected circumstances.

           Both blogs
focus on how impractical, and expensive, maintaining 100% stability or up-time
is. In the first focusing on bugs specifically they give many reasons why this
goal is unadvisable. The first is the prevalence of Agile Development,
dominating nearly the entire software development landscape. As such, the constraints
of this fast-paced development style limit the ability to do traditional QA testing;
if a program can have several revisions in a week, maybe even a day, then how
could a team reasonable test all these iterations. Instead, the author suggest
a stability monitoring tool to automatically test each revision.

           In
addition, they suggest that eliminating 100% of bugs would eliminate many which
users would never see, so why waste resources addressing them? Even if you
could fix everything how could you possibly know? This focus is reinforced when
considering the truly incredible breadth of devices that one may have consider,
and specifically in mobile development: where they cite the over 24,000
different android devices on the market. One must focus on the average expected
user experience and not waste time fussing with the outliers until, presumably,
a bug report is filed.

The second blog discusses
defects in systems in a similar way, covering more or less the same points, although
mentioning a rather obscure possibility: being legally challenged for claiming
that your product has no defects. Instead, what I believe they are trying to emphasize
is that products are always fallible, and the amount of resources required to
get them even close is impossible or impractical. As a result, as we move
forward in this class and towards graduation I think we should resist the impulse
to try for complete perfection and instead focus on what is achievable and
provides the best experience for the majority of users.

Sources

Not all bugs are worth fixing and that’s okay
The Zero Defect Fallacy

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.