Economics of Software Quality

I agree with the article (http://ardalis.com/economics-of-software-quality) in many ways regarding the economics of software quality.  Having worked in the development and IT setting during two co-ops I have see both how the development team has its inner struggles and how those outside of the development view the software.  One reason that I find is nearly the case for low software quality in each development setting is the amount of allotted time.  Considering the time it takes for a team of developers to make a fully functioning and tested application, nearing the end of this process certain APIs may have changed, or requirements may have changed.  In any case the tools used by developers are constantly upgrading, and oftentimes the development team can only image the amount of time they could save had these tools been available sooner.  One practice that is occasionally used in the field is a full re-write of a program after a certain timeframe.  This would mean abandoning the last solution in favor of the newest tools available coupled with the the production knowledge from the last version.  Some developers see this as a necessary evil, others are excited for a fresh start and willing to put the frustrations of an outdated solution behind them, while others abhor the idea and delay it as long as possible.  This method would undoubtedly help to increase the overall quality of the software as it would show dedication from the development and testing groups.

  I also agree for the most part with the reasoning behind production rate and quality.  I do, however believe that this sort of assessment depends on a few different factors.  These factors include the type of software solution, whether it is run once or frequently.  Whether the development team is larger or small, since oftentimes larger groups require more coordination in coding style, lending itself to a higher quality. Third, the importance of software's internals.  Obviously an righteous software developer would care about the internals of their solution, but in certain solutions that handle sensitive information are required by law to have a certain minimum degree of quality.  This thinking can also be applied to what this article states as "the catch-up effect"  meaning that the progression of software testing becomes decreasingly effective as time goes on.  To which degree of confidence a company decides to release the solution is undoubtedly both an economic and business decision to be made.