Embedded Files
In formulating the Five Orders of Ignorance, and reconciling the need for process, I thought I needed to subdivide each of the lower four of the 5OI into triples. These subdivisions are perhaps not as semantically precise as the original 5OI, but they do expose some other aspects of the pursuit of knowledge.
Zero Order Ignorance (0OI)
By definition, 0OI is extant and accessible knowledge. We have 0OI when we know something and can provably demonstrate that we know it. In the book The Laws of Software Process I divided each of the lower four Orders of Ignorance into thirds (eg. "pure" 0OI, 0.1/3OI, and 0.2/3OI). I think this notation is a bit cumbersome. There is a build relationship with these subdivisions—in order to truly have "pure" 0OI, I must resolve all three flavors of Zero Order Ignorance.
But here I will change the "subset" notation to 0OIa, 0OIb, and 0OIc which I hope will be a little more obvious than the original.
Zero Order Ignorance Primary (0OIa): I have 0OIa when I know something,...
...AND I also know how to prove I know something,...
...AND I know how to set up and execute a demonstration of that proof.
Zero Order Ignorance Secondary (0OIb): I have 0OIb when I know something, I know how to prove I know something, but I DON'T know how to display that proof
Zero Order Ignorance Tertiary (0OIc): I have 0OIc when I know something, but I don't know how to prove I know something (and, of course, I don't know how to set up and execute a demonstration of that proof)
We can see that in 0OIb and 0OIc, we actually have significant 1OI present, albeit in a different form than having lack of knowledge of the functional requirements. Presumably, we would know if we did not know how to make a program execute (or play the piano) or how to build and run a test system (or play the piece in front of someone who can affirm the knowledge is present).
So 0OIb and 0OIc are bridges on the path to First Order Ignorance.
Which we will deal with next.
An Example: Beethoven's Moonlight Sonata
Zero Order Ignorance Primary 0OIa
I have 0OIa about Beethoven's Moonlight Sonata on piano if:
(1) I know the piece. and..
(2) I know how to play the piano and...
(3) I know how to set up the demonstration environment to prove I have knowledge of Beethoven's Moonlight Sonata.
Using a negative-proof approach, we can see that each of these steps involve related but different knowledge and application:
I might I know the piece theoretically [1] ,...
...but if I don't have the second step (2) I cannot demonstrate and thereby prove it. The knowledge that separates these two parts is the knowledge of how to actually play the piano at all.
...but I might know the piece and know how to play it, but if I cannot arrange for a piano, at some time and location, and with an audience to whom I can prove I know the piece, I cannot render the provable element of 0OI [2]
Beethoven's Moonlight Sonata
Zero Order Ignorance Secondary (0OIb)
Using my music example: I can play the piece for myself perfectly (as far as I am aware). I (believe I) know how to prove that I can play the piece. But I can't actually prove it because I don't know who, how, and where I play in front of someone who can certify my knowledge [3]
Beethoven's Moonlight Sonata
Zero Order Ignorance Tertiary (0OIc)
And here, I believe I have knowledge of the score, but I can't actually play it on a piano. Therefore any knowledge I may or may not have about how to set up a demonstration of proof is entirely moot.
Another Example: 0OI in Software Development
The source of these ideas originated in software development. The difference between 0OIa, 0OIb, and 0OIc is perhaps somewhat clearer to practitioners in this environment.
0OIa is fully factored knowledge. The requisite knowledge is present in the program PLUS the knowledge of how to make the program actually execute is present PLUS the knowledge necessary to validate and verify the program knowledge is both present and executable. In the software development sphere these are: the program under test, the MAKE process [4] needed to set the program up to execute, and the loaded and executable test system against which the program will run [5] .
0OIb is partially factored and static knowledge. The requisite knowledge is (presumably) present in the source code. However, the programmer or tester has not yet acquired the knowledge of how to render the source code into an executable. This requires further knowledge of the MAKE process (compiling, library linking, etc.)
0OIc is unprovable knowledge. The required knowledge might be present in the program. But the inability to get the program to actually run and the further inability to check the operation of the program in proving (or disproving) that the knowledge contained in the program is "correct" means that the knowledge is unvalidated.
Note that the necessary knowledge to get to 0OIa is distributed between the target program (which is the point of the system development), the MAKE process (which is only loosely coupled to the knowledge in the program), and the test system (which is usually tightly coupled to the knowledge in the program) [6]
FOOTNOTES
[1] It is quite common for members of the audience at a classical music concert to bring the orchestral score and "read along" with the playing to enhance their appreciation of the music. They might be very capable they might be at reading the score, they might know exactly how the piece should sound, what stress should be put on what parts of the score, when it should speed up and slow down, etc. But they are likely quite unable to actually play it.
[2] This is the knowledge of how to actually set up a demonstration. Of course, it may be that I do not need have all this knowledge if the concert is being set up by someone else such as a music professor assessing my proficiency or a promoter setting up a concert. However, I would have to have the knowledge of who this person is and what they know (and can demonstrate). In this case part (3) would simply be the contact information of this person.
[3] ...and because of the Dunning/Kruger syndrome, I might be wholly self-deceived.
[4] A MAKE process is usually another computer program that collects all the necessary libraries and routines needed to make the target program actually run within a computer and renders the source code of the target program into an executable. ...and because of the Dunning/Kruger syndrome, I might be wholly self-deceived.
[5] There are several layers to this test system. Once the target program has been rendered as an executable, a test system will typically: 1. Set the program state and load the program inputs, 2. Initiate an executable cycle of the program, 3. Monitor the program's progress in executing, 4. Produce the required output from the program, 5. Evaluate the quality of the output against some proof criteria, and 6. Produce some analysis of the results. Note, not all of these steps are present in all test systems, but there must be enough to qualify the target program as functional or non-functional.
[6] The knowledge in the MAKE process is mostly related to the development and executable environment. The knowledge in the test system is usually a close analogue of the knowledge that is supposed to be in the program under test. Note that this test system itself must be, somehow, verified and validated.
Page updated
Report abuse