This root cause goes back to the discussion "what is quality?" Defining quality is impossible, as it seems to be "value for somebody" and that somebody changes each time you ask a different person the question. Knowing what is meant by quality is vital, if you want to strive for it. Only by having an explicit quality goal can you truly know where you should be and where you are at any given moment. In other words, you need to have a target. You need to know whether it is performance you need to tweak or if a good quality system in your project means as robust as possible, or as maintainable as can be.

Knowledge comes into play also as knowledge about the system and workings of the project and organization. If you understand that by shortchanging quality for time now actually means wasting time later, the knowledge helps you prevent the mistake. If you, however, have a wrong kind of paradigm, for example, that you can test quality into the product, you will resort to foolish things in trying to reach the desired quality level. The Fixing Fallacy is supposed to clearly show how a defective paradigm can hurt a project in practice. Changing the paradigm means changing how and what people think and that is always difficult. The root cause persists because of the fairly long time frames between stimulus and response. The consequences of wrong actions show themselves much later so that the cause-and-effect connection is difficult to notice. It makes for a perfect sign, noticeable by a doctor but not by the patient.

The conclusion of Chapter 3. "Root Causes" is that there are exactly four ultimate reasons for failure in software. One of them is lack of knowledge.