The Challenge of Good Enough Software

Software quality is a growing critical aspect today. This is because customers are more sophisticated, technology is getting more complicated and the software business is becoming more intensely competitive.

When it comes to software, quality is a growing important aspect as clients are more sophisticated, the technology is more complex and the software industry gets more intensely competitive. Nonetheless, there’s a powerful option for the costly, orthodox and boring methods that aim for the best possible software quality. An option that’s the secret to Microsoft’s success as well as other organizations, and this is the discipline of good enough software development.

This discipline could also be considered a utilitarian approach. To create good enough software requires specific processes and methods that almost are ignored universally or devalued.


Quality software is not so simple in the field wherein requirements change and fade, similar to a desert mirage, where projects perpetually are understaffed and behind schedule, the QA often is a fancy word for ad hoc testing and management appears to be more interested in business rather than in the necessities of software engineering. Often, quality is talked as if it was a substance, something that in principle can be bread from a gauge. However, quality is more of an optical illusion, a complex abstraction that in part emerges from the observed and part from an observer and party from the observation process itself.

Software is viewed aesthetically, which means that quality is elegance. Often, this view is held by developers, who may describe a product in terms of its different attributes, yet could not describe the idea unambiguously. This view has to be considered since it boosts morale and could lead to pride in one’s workmanship. A risk of this view is that it could be a cloak for underachievers and perfectionists.


In the viewpoint of a manufacturer, software quality is correctness and adherence to specifications. This perception leaves open the entire issue of building a quality product and thus is not much help in the design problem, nor in the problem of comparing the relative relevance of different none conformances. The danger is this view is that a developer could create a perfect product that satisfies nobody.


In a customer’s viewpoint, software quality is fitness for use, whatever satisfies one. The problem in this view is that quality becomes not just subjective, the same as in the aesthetic view but one also lose control of it. Who the customers are, how to integrate their values to a software product that they have not seen are just some of the concerns. There can be more than one customers, or else customers do not now that they want. The danger in this view is that developers could find themselves chasing a whim-of-the-wisp rather than creating a product that would be happily accepted as soon as customers experience it.

With the viewpoints mentioned above, we could identify specific factors which are characteristic of a quality software. The ISO 9126 standard has such attributes, arranged in areas that include the functionality, reliability, efficiency, maintainability, efficiency and portability.

Quality assurance would look like a matter of product assessment for the presence of every quality factor with respect to each of the views. However, the problem is not that easy. In a certain context, some factors are more relevant compared to the others. Some detract from others, as in the conflict of the classic functionality-versus-portability. For most of the factors identified, there are no simple nor inexpensive ways of measuring them, nor compose each of the factors once measured to an overall quality metric.

The customers, whether internal or external, would never now the quality of products. They would create a quality perception and act on this basis, whether or not it matches the developers’’ perception. The perception of a customer will depend among other things on their talent, past experience, values and profile of use. Some factors could be studied, but none could be controlled.


Software quality is inhibited by the system’s complexity, its invisibility, sensitivity to small mistakes, interaction with outside components as we as the interaction with the individual user. Creating software of the best quality possible is an extremely costly proposition. On the other hand, customers may not even notices the difference between the best quality possible and quality that is pretty good. This leads to three vital questions: How much of what quality factors will be adequate, how to control it adequately and how to measure it adequately.

One answer to these queries is to punt on the entire measurable quality notion. Rather than using one’s head to build a universal quality metric and working to optimize everything versus that metric, one could make use of the head to consider the issues that quality supposedly will solve directly. When those issues are resolved, automatically there is good enough quality software.

Good enough software means a product developed by a software development company that is appropriate not just to one customer but for several customers too. When the challenge of good enough software is solved, then it is considered a good enough quality product indeed.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.