WHAT IS QUALITY SOFTWARE?
“Thus spake the master programmer: A well-written program is its own heaven; a poorly-written program is its own hell.'''' (James, 1996)
My view of quality software stems from having written applications for users with varying degrees of ‘computing aptitude’. I have written software for users that can be defined as “power users” as well as those that picked their mouse up off the desk and tried to use it like a remote control (really, the lady should not have been given a computer at all). But, the underlying factor of quality in every application that I have ever written is that is in the eyes of the user. Programmers provide a service/product to users who evaluate our product based on what ‘they’ think it should do. If it does not meet their expectations (no matter if they are unreasonable) then the product fails its quality test. If the product in question is a part of a larger system that fails to meet the user’s expectations, all parts of the system fail. The user (read customer) is always right.
I have an example that I would like to bring up. I was contracted to a large telecommunications company here in Alabama to write a software application to replace a certain set of functionality in an existing application. The software replacement was written in three separate pieces, my team’s piece being accessible only by traversing through the other two, which collected data and passed into ours via programming interfaces. After implementation of the application suite, it was noticed that users were not using our application as much as anticipated, and were continuing to use the previous application. After researching the issue, it was discovered that user’s in the field absolutely loved my teams particular part of the application, but the two applications that had to be ran to get to us were so disliked that they were never launched, and so neither was our application. The quality of the system as a whole was seen as lacking, therefore our application, even though seen as being of good quality singularly, was branded as bad, and subsequently not used. We had to re-design the product to not require the interfaces to the other applications, at significant cost, before the perceived quality of the application was brought up to an acceptable level in the users eyes.
Carl Frappoalo states in Bernard’s (2003) article that organizations should not overlook the need for adequate training on the new systems being implemented. I completely agree with that statement. Many applications will fail to be adopted and embraced by the user simply through understanding of what that application is there for and how it can help them. Quality will suffer in the face of poor understanding, both on the point mentioned above and as outlined throughout the article. Poor understanding of requirements, of what is the true impact of the system(s), and of how to implement and create those systems will truly impact quality, sometimes fatally.
References:
Bernard, A. (2003). Why implementations fail: The human factor. Retrieved from http://www.cioupdate.com/insights/article.php/3293281
James, G. (1996). The Tao of Programming. Retrieved from http://www.canonical.org/~kragen/tao-of-programming.html
Comments
ggrphrfm commented, on August 17, 2008 at 7:28 a.m.:
RuW4EK <a href="http://ifwovneoizus.com/">ifwovneoizus</a>, [url=http://pplkhjmjmhkh.com/]pplkhjmjmhkh[/url], [link=http://ipramosulsdi.com/]ipramosulsdi[/link], http://ldeeilxivuqp.com/
