Crosby’s 4 Absolutes of Quality in a Software Context

Philip Crosby is a well-known quality leader in the manufacturing sector. He has written many books about quality from 1968 to 1999.

His most well-known work, which he frequently quotes on is “quality is free”, zero defects through prevention, and his “4 absolutes” of quality.

These things were discussed by Crosby in the context of his manufacturing production line companies. However, Crosby’s lessons can be directly transferred to the software industry without any doubt.

I have been involved in numerous twitter conversations about Crosby’s work in the past and have read his books. This blog will share my thoughts on Crosby’s “4 absolutes quality” book, “Quality is Free”. These 4 absolutes are what I believe underpin conversations about zero defects through prevention, and quality being unaffected.

(Note: Crosby’s work can be admired in large quantities! This blog is not intended to criticize Crosby’s work. This blog is not intended to show how Crosby’s framework has been used by me in my work with software. You can agree with me or disagree with my views. That’s okay! This is me simply sharing my knowledge and outlook on the world of quality ).

The 4 Absolutes of Quality

These are the details:

  1. Conformance to requirements is a definition of quality.
  2. Prevention is the best way to cause quality, and not appraisal.
  3. Performance standards must not be broken.
  4. Quality is measured by the Price of Nonconformance.

I will ask you to not think about these in a software-oriented way. As that is the context in which these were created, think of them first from a hardware manufacturing perspective.

Working in the hardware manufacturing industry, I was able to see the production lines from the floor and test hardware and firmware. I gained a first-hand understanding of Quality Assurance and Quality Control from this context. These terms have also been translated to the software industry, but I don’t think they fit in the context of building software. Photobox’s current context also includes a lot of manufacturing line manufacturing. People use Photobox to order printed gifts such as photobooks, photo prints and canvases, mugs. cards. phone covers. jigsaw puzzles. The manufacturing lines at Photobox are amazing – printing thousands upon thousands of images onto products, then packing them with care in cleverly designed packaging. Customers can look forward to seeing their best moments on the product they choose.

These 4 absolutes seem reasonable when viewed from the perspective of a production line.

This is not hardware design or the creation of a hardware product. The manufacturing line is what I am referring to. The manufacturing line is responsible for building the products according to a set specification.

It is not possible to make hardware products the same way each time. Each product must meet that specification. Each manufactured product that fits the mould can be considered a quality indicator of manufacturing. Any deviation from the mould would be considered a defect. Quality control is the act of inspecting a portion of manufactured products for any “defects”. Non-conformance to hardware specifications is a way to find deviations and feed back to solve problems related to the production line. This could be machinery that is failing or people making mistakes or the production line trying to move too fast, etc.

This whole idea is tied to the notion that quality is “correctness”, in this hardware context. When the goal is to make the same product over and over again in exactly the same way, correctness is what people look through.

As you can see, the numbers 1 through 4 make sense when placed in this context.

When you consider putting effort into the design for the production line processes, number 2 is logical.

Hardware mistakes can be very expensive. Although it might seem like a success to find defects before shipping products to customers, consider the cost of the materials and time required to reset the production line to fix the defect. Hardware manufacturing should be as defect-free as possible.

But what do you think about software?

It is difficult to simply transfer the 4 absolutes to software.

Software doesn’t just involve creating a product, then setting up a production line to produce it over and again. The product will then be shipped to customers. Software is much more dynamic than this. Software is not a building problem, but a thinking challenge. Software is a complex web of variables.

While we can help customers define their needs and wants, there are many ways that developers can write code using different tools. Software complexity can also be influenced by the customers and users. It is subjective and dependent on what they need and want. Each user will have a different experience.

There are many variables that can affect how users use the software. This includes what data they use and where they use them. It also impacts how they feel about the software.

Hardware tends to serve a particular purpose. Headphones can be worn on your ears or placed in your ear to convert information into sound. You can listen to the recorded sounds through headphones privately. A mug can hold either hot or cold liquid and has an ambidextrous handle that allows people to lift the liquid and drink it. A monitor is a device that displays information from a computer or another device. It converts the data into pixels and places them accordingly to create an image that people can see.

They were designed for a single purpose and are used by people to fulfill that purpose.

They do contain software and firmware, which are part the manufactured product. However, the firmware and software are not manufactured in the same manner as the hardware.

Recalling the 4 Absolutes in Software Thinking:

  1. Conformance to requirements is a definition of quality.
  2. Prevention is the best way to cause quality, and not appraisal.
  3. Performance standards must not be broken.
  4. Quality is measured by the Price of Nonconformance.

Absolute #1 Quality is defined by conformance to

This is not possible in a software environment. Requirements are important. Customers have needs and wants. There will always be expectations and we must build the software to meet them. There are many unknowns due to the complexity of software and the variables involved in building software. Unexpected events that are not known about the requirements… To say that quality equals conformance to requirements would ignore the holistic view of the software. This includes both the requirements and actuals of its usage. It also takes into consideration the spectrum of ignorance and knowledge (lack thereof).

It doesn’t feel right. Software quality is not about “correctness”. Software can work “correctly” according to the requirements but can also be very difficult to use due to something unexpected.

It is important to look at software quality from a wider perspective, “goodness. The customer’s experience with the software will vary depending on whether it is a delight or a disappointment. This can be done by looking beyond the requirements and into the realms product risks and investigating unknowns. This is the extent to which the software can be used well or poorly.

Absolute #2: Quality is achieved by prevention and not through appraisal.

Preventive/exploratory testing is a key part of software quality management. You can perform investigative/exploratory testing against the idea of the software solution, then again on the artefacts and UX/UI wireframe designs, and on the architecture design and the code design – the information uncovered will relate to different kinds of: risks, variables, perspectives, ambiguities, properties, purposes, unknowns, etc.

This information can be used to improve designs, and code design. It will also help prevent many of these risks from resulting in problems within the software. Awareness or the risks and unknowns is what makes prevention possible, and investigative/exploratory testing is the perfect approach to uncover and breed awareness of these things throughout the early activities of the SDLC, before any code is written.

However, this does not mean that you can consider every possible risk or variable. Human beings are not perfect. We are human. However, ignorance is still a factor. There are unknowns we won’t be able to prevent.

Software quality is not possible without prevention. The investigative testing activities are still necessary to test the code and the operation software. This is where the output of testing is more relevant to problems. Yes, we find risks in the SDLC, but once that happens, we can conduct further investigations to determine if there are actual problems.

Absolute 3: Performance standards must be zero defects.

This statement seems a little moot when you consider the psychology of the unknowns.

In the context of software, I believe “zero defects” should be interpreted differently – known defect”. This means that any defect or problem should be addressed as soon as it is found. It is important to identify it and then work towards fixing it. This also acknowledges the fact that not all defects are known. We can’t see everything. There will always be unknowns. Also, just close the bug if is chosen, not to fix it.

Personally, I prefer to see the performance standard for software-quality quality as a function of risks. This includes risks discovered, design risks, investigation risks, and problems that have been caused by them. These can be quantitative or qualitative, but they ultimately build confidence in our perception of quality.

Absolute #4: Quality is measured by the Price of Nonconformance

It seems to me that it implies problems related to “correctness” or specifically, software that is not in line with the requirements. As I have already said, requirements are not the only thing. Also, requirements can be misinterpreted or wrongly interpreted if they are unclear (it’s similar to the “Mary had some lambs” statement. Did Mary have a pet lamb? Or was it that she ate a bit of lamb for her dinner ?…

Again, #4 is a part of the overall picture. We do need to look at the scale of correctness/incorrectness as we will have expectations set from requirements. We must also look beyond the requirements at the software and its ideas to determine the scale of goodness or evil.

It is difficult to measure the quality of software. Software quality is subjective and relative, as I have already mentioned. Quality is subjective and relative. As are bugs/defects/problems. Any measurement of quality is therefore representative of the viewpoint of the individual or team that is evaluating the quality of the software.

We can also use data from software users in their own context. This will allow us to gain insight into the user’s experience with the software. It is important to recognize that there are business risks when you release software to users. The software may be terrible at a basic level. This could lead to users becoming more frustrated with the software and could impact your business reputation or company margins if they choose to go to a competitor.

My preference is to use a mixed approach. You need data from users, but also you want to understand quality from your perspective.

These are the reasons why I believe that Philip Crosby’s 4 absolutes do not work well in a context of software. They can lead to misperceptions in the software industry if they are blindly incorporated into a software context.

My adaptations to the 4 absolutes quality for use in a software context

With the above in mind I would like to suggest some modifications to the 4 absolutes, if you use them in a software context.

  1. Quality can be defined as “correctness” and “goodness” in relation with stakeholder value.
  2. Preventing quality and detection are the keys to quality, followed by action.
  3. One performance standard is “zero knowndefects”, while others are “risk detection” and “risk mitigation”.
  4. Quality is subjective, relative, and personal. Therefore, it refers to confidence in perceived quality.

A positive ending

Crosby was a great promoter of quality in the hardware industry. I’ll leave you with Crosby’s quote, which I believe is an important message that applies to all industries, including software.

Quality is the result of carefully designed cultural environments. It must be part of the fabric em>

Philip Crosby

This quote resonates with me because it reflects how I think companies should approach this issue from an organizational cultural level. Quality should not be an added-on after something has been built.