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.