More  Detailed Orders of Ignorance (3OI)
Ignorance and Process

More subdivisions of the 5OI.   With Third Order Ignorance, rather than parsing knowledge, we look at intention in the application of process.  

Third Order Ignorance (3OI)

Basic 3OI is the lack of a suitably effective way to find out if (and what) Second Order Ignorance I might have.  It is a process level.  Coupled with 2OI, 3OI typically results in a dead end; there are things I don't know that I don't know and I don't have a way to find them out--given the time and resources available to me.

Suitably effective also pertains to the goal.  If I have to deliver a fully functioning product to a customer and I have 2OI about aspects of that functioning, such ignorance will be embedded in the product.  The ignorance will be exposed (in software systems) by the presence of bugs when they manifest themselves.  Earlier, I called the sudden appearance of "bugs" [1]  an "epiphany of ignorance" and it is.  Whatever caused this appearance is a de facto Third Order Ignorance process.  But, when the bugs appear in production and in the final customer's environment, it could be considered neither a suitable nor effective process--certainly from the point of view of the customer.

Such a 3OI process might be considered accidental or unintentional.  And the subdivisions of 3OI deal with such.  These levels of ignorance also occur when, consciously or unconsciously, don't want to expose our ignorance.

Third Order Ignorance Prime (3OIa): I have 3OIa when I don't know of a way to find out I don't know something,...
...BUT I am intentionally working to find a way to expose my 2OI,...
...AND I am intending to learn from what the process tells me

3OI can be rather daunting in practice.  Solid application of a 3OI process explicitly shows me that I don't know something that I didn't know  As mentioned earlier, this is often uncomfortable.  Even worse, a 3OI process doesn't give me the answer, it merely shows me that I don't have the answer; it may even show I don't have the question.  Even worse, in software execution, a good 3OI process will graphically point out the deficiencies in a product I may have been working on for a long time.  Ouch.

Third Order Ignorance Secondary (3OIb): I have 3OIb when I don't know of a way to find out I don't know something,..
...BUT I am actively using processes that are not suitable and don't work effectively,...
...HOWEVER, I will accept the (negative) results if the process happens to stumble upon them.

I called this "unintentional process ignorance".  It is quite common in software development and is caused by the Lemma of Eternal Lateness.  Simply put, we tend to apply processes which have worked, or seemed to have worked, for us in the past.  This is a natural learning curve.  When confronting something new, we have to start the processing somehow and our previous experience, in as close a match as we can make, is a logical place to do this.  It might even be quite effective, but the results are often serendipitous rather than intentional.

Third Order Ignorance Tertiary (3OIc): I have 3OIc when I don't know of a way to find out I don't know something,... 
...AND I will actively use processes that will not expose that ignorance.

I called this "intentional process ignorance".   In its truly intentinal form, it is pernicious.  An example would be a scientist intentionally using a process that he/she knows or suspects doesn't work but will give the answer wanted.  Of course, we could consider this example to not looking for knowledge since the premise is that the "knowledge" (more correctly, the desired answer) has already been determined.  In the software field, receiving pressure from management to fudge results, avoid tracking defects, or simply repeat tests that have already been done would be another example.  Sadly, in my experience, this was a very common attitude taken by some managment in some companies.

The underlying reason for management adopting this approach is simply their Fourth Order Ignorance.  Which is next.

FOOTNOTES 

[1]   The word "bug" as it applies to a software defect is usually credited to Captain (later Admiral) Grace Hopper when running a test sequence on a Mark II computer at Harvard and found that a moth had shorted out a relay.  She wrote: "First actual case of bug being found" next to the bug taped in the run log.  The word "bug" probably comes from a Middle English (bugge=scarecrow) and Welsh (bwg=goblin or similar scary thing)