I think it’s more than a decade ago I stumbled over the concept of “Orders of Ignorance”. I like it - for whatever reason. So, I decided to write a post about it and frame it with my personal experience.

Software development is often seen as a straightforward process of writing code.

However, experience tells us that the real challenge lies not in the coding itself, but in acquiring the necessary knowledge.

This blog post explores the concept of the “Five Orders of Ignorance” ( Citation: Armour, 2000 Armour, P. (2000). The five orders of ignorance. Communications of the ACM, 43. https://doi.org/10.1145/352183.352194 ) , introduced by Phillip G. Armour, and its implications in software development.

Introduction: The Real Challenge in Software Development#

Where ever I look, the observation in software development is that tasks often take longer than expected. The crux of the problem is not the act of coding but the acquisition of knowledge.

Reading code can be such an activity, understanding a framework you never worked with or getting user feedback early.

Therefore, Armour points out, software is not just a product but a medium for storing knowledge, making software development a knowledge-acquiring activity.

The Five Orders of Ignorance in Software Development#

One note before starting to explain the different levels of ignorance.

Knowledge in this term really means to know how to do things. It’s now like, I watched a youtube video how amazon scales to a billion users, and now I know how to build large scaling systems.

Knowledge in this post means: Proven executable knowledge - Explicit knowledge or Tacit knowledge

0th Order Ignorance (0OI): Lack of Ignorance#

At 0OI, there’s a complete understanding of a topic.

In software development, this translates to knowing how to build a system that satisfies user needs. It is the stage where a developer has complete knowledge about the task at hand.

Example: A developer who has repeatedly built e-commerce websites has 0OI about this type of system.

Hopefully, this never happens 😆 !

1st Order Ignorance (1OI): Lack of Knowledge#

This level signifies awareness of one’s ignorance. You know that you don’t know, but you are able to formulate a useful question and acquire the knowledge.

What do I mean by useful question? Well, I don’t know how to build a fusion power plant and I could ask the following question:

How to build a fusion power plant?

But since there is no one to answer the question, it’s pretty useless, right?

Example: You don’t know how to implement a little form with vue.js, but you know many sources to ask and where to find the knowledge.

In the era of Chat GPT, Github Copilot and Jetbrains AI, we could re-phrase this level of ignorance to:

You know a useful prompt to something you don’t know!

2nd Order Ignorance (2OI): Lack of Awareness#

Welcome to world of unknown unknowns.

Let’s watch the most prominent explanation of this ignorance level:

Crystal clear? 🤔 No?

At this stage, you are unaware of your ignorance.

You don’t know that you don’t know, but you have process to discover the unknown unknowns (beside the trivial process to build the system). A short-cut. You don’t need to build the full system to discover the unknown unknowns.

This is often the starting point for many software projects, where the extent of knowledge required is unknown.

Example: You are part of a game development team and instead of designing the full game, you implement a proof of concept and let potential alpha users test the idea of the very rough concept of the game.

Whenever you apply an agile development approach, you apply a process to reduce your level of unknown unknowns.

3rd Order Ignorance (3OI): Lack of Process#

This order involves not knowing a process to discover what you don’t know. It’s a significant challenge in software development as it impedes the ability to convert unknowns into knowns.

You have to build the entire system to find out what you don’t know. There’s no easier way to do it.

Example: Before building Chat GPT 3, OpenAI did not have any idea regarding its power; they simply believed in the system and proceeded with its development.

4th Order Ignorance (4OI): Meta Ignorance#

Every scientist loves this. There is even a meta level of ignorance 😄 !

This is ignorance of the FOI framework itself. Understanding and acknowledging these orders of ignorance is crucial in effectively managing knowledge in software development.

Congratulations: By reading this, … you get it!

Planning and Execution in Software Development#

Planning with 0OI is straightforward, as all necessary knowledge is already acquired. With 1OI, planning is still feasible as the unknowns are identified.

However, at 2OI, more exploratory and flexible approaches like agile methodologies are crucial, as the unknowns are yet to be discovered.

What does this mean and how does it help in my day-to-day job as a developer, you might ask.

Implementing a Feature: A Practical Approach#

Imagine you’re in a team set to work on a new feature that should be done in a week. If your team has done something similar before, splitting up the work and coding together can work well.

But if there’s stuff about the feature you don’t know yet chances are high that there are unknown unknowns as well, and it’s a good idea to try a small test or a basic version first. This way, you can figure out the unknown parts and get a better handle on the project.

In short: Whenever you have to do something you haven’t done before, try to formulate a little experiment.

Challenge yourself and tackle the most difficult part first.

The PopcornFlow describes the concept of little experiments very good:

Conclusion#

Understanding the Five Orders of Ignorance provides valuable insights into software development.

It helps teams identify their knowledge gaps and choose appropriate methodologies to address them. By acknowledging and working through these orders, software development can become a more predictable and efficient process.

This awareness is key to managing the inherent uncertainties in software development and ultimately leads to the creation of robust and reliable software systems.

References#