Embedded Files
This is the final subdivision of the 5OI. Or not.
I have Fourth Order Ignorance (4OI) when I don't know about the Five Orders of Ignorance.
4OI is a form of meta-ignorance—ignorance about ignorance. Not 1OI or the 2OI forms of ignorance, which are about what I don't know, but ignorance of the concept of ignorance [1].
As mentioned earlier, I originally added 4OI to the lower orders of ignorance out of a love of recursion. Then, as I thought further about knowledge and ignorance, it became clear that all knowledge and all ignorance is inherently self-referential and recursive. So capping the 5OI with something that is extrinsically self-referential (4OI refers to the other orders of ignorance) and intrinsically self-referential (it refers to itself so 4OI contains 4OI) seemed appropriate. And kind of cute.
One could easily dismiss the importance of 4OI, making arguments such as:
I know a lot about knowledge and ignorance, but I just hadn't heard specifically about the Five Orders of Ignorance.
4OI is not a functional level. Knowing about it doesn't really increase my functional knowledge, except for finding out about this particular (4OI) label.
I don't really need to know about 4OI [2] , all I really need is the lower levels.
Indeed, 4OI is a concept rather than a practical step. But, after spending decades in the profession of software development, I think 4OI might be the most destructive of all.
My experience has been that almost all software development businesses consider their job to be to build and ship software or products containing software. Sounds reasonable, right? But it is not correct; the real job is not to build and ship systems, it is to learn.
When I've confronted people in charge of running such businesses with this idea, I've mostly received blank stares. Many have scoffed at the idea. Almost all have ignored the idea. As have mentioned, often, the real product is not software; software is merely the container for the real product. More correctly it is one of the containers of the real product—the other containers being the brains of the developers and the paper of the specifications and designs. But the software container is the only one that actually executes the knowledge. Some of the knowledge-in-software is resident in repositories that are not populated by the application developers but exist in the operating systems, the programming language functions, and the various libraries available to, and needed by, the final product. While the application developers might not create the knowledge in these sources, they do need to know what that knowledge is, where it located, how to access it, and how to use it in the context of their overall solution [3] .
Almost all development organizations focus solely on the software "product" and do a very poor job of managing the knowledge that goes into the software product and how it gets there. True, companies in the business of software development have become better at developing their application reuse libraries over the years. But then they often fail to maintain them and the resident knowledge becomes corrupted or simply ages out. Programming languages have made great strides in encapsulating executable knowledge into the language syntax, but the developers still need to acquire the knowledge of how to use that syntax [4]
4OI Inaction: An Example
Many years ago I was conducting a workshop on development methods to telecom companies. In the middle of one workshop, a good number of the attendees learned that their project had just been canceled. Indeed, the company had just cancelled the entire product line. Their company's powers-that-be decided they couldn't make a profit from the box they had built, so they just pulled the plug. [5]
The project that had been canceled was an in-building over-the-air ethernet Wi-Fi hub. Financial calculations showed that the company couldn't make the product for a price point where people would actually buy it and they would lose money trying to sell it [6]. So management canned the whole thing, split up the development team, and tried to forget about it.
What the company didn't do was capture the knowledge that had been painstakingly acquired in building this product. Had they done so, done it effectively, and then used the hard-won knowledge to build the next and next-next generation of these boxes. they would have had a five-to-ten year lead over other companies in consumer Wi-Fi. And they would have made a fortune. But they didn't. The company management viewed the box as the product, figured they couldn't make money on that particular box, and threw what they had learned out the window.
This is 4OI in operation—it is not understanding that:
The job is to learn...
...the real product is knowledge...
...and, if you keep it, you own it, and you build on it, that knowledge can be very, very profitable.
FOOTNOTES
[1] Arguably, 4OI could be considered to be a form of 1OI where the target is ignorance itself. Or it could be thought of as 2OI since the target is not defined (apart from the "ignorance" label). It could even be considered as a form of 3OI since it is so ill-defined that a suitably effective process to alleviate must be equally ill-defined. Of course, the only way to have 0OI of 4OI would be if all varieties of ignorance were fully known, which is impossible. Therefore, 4OI could be thought of as other flavors of the other Orders of Ignorance.
So, yeah, it's recursive.
[2] There were originally only four orders of ignorance. 4OI evolved along with the thinking about the lower orders. So I guess, I had 4OI until I didn't.
[3] While the quantity of knowledge needed for language reuse is often a lot less—otherwise, why use the language—it can still be considerable. And there is always an intersection between knowing the language functions and knowing how to use them for the application at hand. That knowledge will still need to be obtained.
[4] My personal experience of books devoted to programming language functions is that they seem to explain how to use functions in the "usual" way, something I already know, but they can rarely explain how to use the functions the way I want to use them in this particular instance. I then have to rely on a form of black box testing to find out what they will really do when executed. It is in executing them to see how they really work, I am able to store what I've learned in the knowledge-in-brains medium before translating into the knowledge-in-software medium.
[5] The workshop then morphed into a job fair as those folks who has just lost their jobs started asking the other attendees if there were openings on their projects at their companies.,
[56 There were many limitations of this particular box, The primary one was that power limitations required line-of-sight to the hubs being serviced. Of course, if you have the latitude to arrange your computers in line-of-sight, you can probably run twisted pair under the carpet or under the flooring and you don't need Wi-Fi. Had the company leveraged what they learned and used that as a basis to build more powerful boxes, they could have broken open a whole new technology market.
Page updated
Report abuse