One of my personal favourite books is Zen and the Art of Motorcycle Maintenance, it is a book which discusses quality through the use of dissecting Western and Eastern philosophies. Its basic thesis is that the fundamental driver of human life is the pursuit of quality. Quality by definition is having a high set of standards as measured against things of a similar kind, or a distinctive attribute possessed by something.

This definition though vague gives us a fairly simple context, for example it's completely valid to say that Apple makes high quality laptops. But we only derive that Apple’s laptops are high quality by comparing them to the other laptops to determine what is the general standard. Sometimes this is done through communication of expectations. Meaning if a machine is expected to handle a video game and it fails to our rating of its quality diminishes.

Secondly we must examine what it means to possess quality. To possess quality something must be comparable to similar things, and it must have characteristics which similar things do not have which distinguish it as having quality.

So how does one measure software quality? Software is a thing which can have numerous definitions, it all depends on the audience being questioned. We must examine this from a few to determine how we can truly measure software quality. Let’s take a look at three points of view: Developer, Business and Customer, these are all points of view we can relate to.

The business is the primary driver of most software. They determine through the input from the development team and customers how much effort has to be put into code for any given project. The do this by determining budgets and timeframes for features. High quality code is not a given in this case as functional code does not have to be high quality. The business looks at software as a sellable product similar to an action figure. To the business quality is measured by the adherence to the deadlines and budgets and what their expectation is on those elements. Development teams who communicate clearly to the business team that more time is needed may improve the quality rating of the business team, particularly when a compromise is made that if delivery is delayed it can result in higher performance thereby attracting more customers.

The customer has a similar point of view. Their concern is rarely whether or not something is made with native code or some HTML5 package interpreting toolset. They’re not concerned with the readability of the code. They’re concerned with their information safety and the experience of using the software. To them code quality is not even a concept, their concern is solely with the quality of the experience, which is entirely valid. Customer’s are primarily interested in what they are expecting to experience which means that the business team must communicate clearly what a software can and cannot do, and not mislead customers. Any time a customer is misled that will directly relate to a poor quality rating.

Developers are often concerned with code quality as measured by some mechanism which examines based on limited perspectives of adherence to style standards, test coverage, and complexity of methods. Architectural quality is a harder form of measurement as there are numerous view points on what is considered high quality in that situation. So from a developer’s standpoint, it's rarely a concern about the deadline and budget, and though user experience is of high importance the quality of the code in their eyes is based on the scores defined by the tools they use and (hopefully) the readability of their code. They know the code must comply with what the business is expecting but at times developer’s will make adjustments to allow for faster development or less complex development which may alter the plans of the business. If developers are under high pressure for a deadline and budget, it is likely that they may prioritize pragmatic code over elegant code which can result in a poor quality rating

This means software is actually measured in many ways and its quality is never defined by any singular group of people. Quality is not an inherent aspect of code, it is in fact a feature unto itself, after all quality is defined as an attribute or characteristic. Since code quality is a aspect defined differently depending on various points of view, we can only judge a software’s quality based on the average of these views assuming each viewpoint is a percentage of quality. One must also bear in mind that the points of view which control the profitability of a software project have higher value in their percentages.

This means that a code project could easily be successful if the customers and business are happy but the developers are disappointed with what was built. Software is fundamentally a compromise of various view points in order to develop something that makes the most groups happy which is how the attribute of quality is determined.

B = Business Quality = 0.80
C = Customer Quality = 0.80
D = Developer Quality = 0.25

Q = μ (B * 0.35) + (C * 0.4) + (D * 0.25)


Q = 66.25%

The above example demonstrates how poor code quality code can still result in a decent quality software project. The reality of this is that when groups are examining software projects they must look at each viewpoint in order to determine the quality of the project. When investors are examining a new investment to take on they will likely consider these viewpoints speculating the customer quality rating and developer quality rating before they make a choice based on their own business quality rating.

In conclusion, quality is an attribute given to a project based on the standards it adheres to and exceeds. And to determine the quality of a software project one must consider the various viewpoints which are scrutinizing the project. Therefore, the goal of all teams building a software project should be to ensure that all viewpoints involved in a project get the highest quality rating through compromise and communication of expectations.