Phillip G. Armour says that "software is not a product, but rather a medium for the storage of knowledge" in a short article titled The Five Orders of Ignorance in the 2000 issue of the Communications of the ACM.
It’s rather easy to produce software. It’s much more difficult to produce software that works, because we have to understand the meaning of “works.” It’s easy to produce simple software because it doesn’t contain much knowledge. Software is easier to produce using an application generator, because much of the knowledge is already stored in the application generator. Software is easy to produce if I’ve already produced this type of system before, because I have already obtained the necessary knowledge.
So, the hard part of building systems is not building them, it’s knowing what to build—it’s in acquiring the necessary knowledge. This leads us to another observation: if software is not a product but a medium for storing knowledge, then software development is not a product-producing activity, it is a knowledge-acquiring activity.
...the real job is not writing the code, or even building the system—it is acquiring the necessary knowledge to build the system. When hacking, we use the activity of building the system (or rather attempting to build the system) as our mechanism for understanding what the system has to do. Code is simply a by-product of this activity. The problem arises when we think the code, rather than the knowledge in the code, is the product.
hand-in-hand with acquiring knowledge is the removing ignorance and Armour has come up with 5 levels:
0th Order Ignorance (0OI)—Lack of Ignorance.
You know, you have the answer.
1st Order Ignorance (1OI)—Lack of Knowledge.
You know what you don't know, you have the question.
2nd Order Ignorance (2OI)—Lack of Awareness.
You don't know what you don't know.
3rd Order Ignorance (3OI)—Lack of Process.
You have no means, or process, for resolving your lack of knowledge.
4th Order Ignorance (4OI)—Meta Ignorance.
Not aware of these 5 levels.
Major problems in software development occur when you have 3OI. 2OI is inevitable but you must have a means of uncovering the questions.
The application of 3OI to 2OI generates either 1OI or more rarely 0OI—the process either gives us the answer (0OI) or more commonly, it gives us the question (1OI). This is one of the major purposes of process and is the major role of methodologies and modeling.
The critical point here is that the application of 3OI processes (methodologies and process) does not give the answer; it gives me the question. As a business model,
we have been looking to these tools for the wrong thing. We expect them to provide us with answers, and that’s not what they do. It is very frustrating to expect an answer and instead get a question; to use a methodology to reduce the amount of work, and apparently increase it; or to conscientiously apply a process only to have it tell us just how little we actually know. But that is the reality of the software development business. A functioning system is the by-product of the activity of finding things out. The working system is the proof that I have the knowledge. Looked at pragmatically, the goal is to resolve our orders of ignorance to 0OI. We spend most of our energies acquiring knowledge. Since finding the
answer to 1OI is straightforward, we must be spending most of our production energy on 2OI, and
most of our process energy on 3OI. We can use the Orders of Ignorance to categorize what we know, and what we don’t know, to estimate the likelihood of what we don’t know we don’t know, and to assign to process and methodology their true place in the order of things.
