Back in 2000, Philip Armour published an article called Five Orders of Ignorance (Communications of the ACM, Volume 43 Issue 10, Oct. 2000), with a subtitle Viewing software development as knowledge acquisition and ignorance reduction. This message very much correlates with a quite of Alberto from the previous section, although is rather less catchy but by no mean less powerful. The article argues that increasing domain knowledge and decreasing ignorance are two keys to creating software that delivers value.

The article concentrates on ignorance and identifies five levels of it:

1. Zero ignorance level is the lowest. On this level, you have no ignorance since you got most knowledge and know what to do an how to do it.
2. The first level is when you don't know something but you realize and accept this fact. You want to get more knowledge and decrease ignorance to level zero, so you have channels to obtain the knowledge.
3. The second level is when you don't know that you don't know. Most commonly this occurs when you get a specification that describes a solution without specifying, which problem this solution is trying to solve. This level can also be observed when people pretend to have competence they do not possess, at the same time being ignorant to this. Such people might be lacking both business and technical knowledge. A lot of wrong decisions are made at this level of ignorance.
4. The third level is when you don't even know how to find out that you don't know something. It is very hard to do anything on this level since obviously there is no way to access end customer even to ask if you understand their problem or not, in order to get down to level two. Building a system might be the only choice in this case, since it will be the only way to get any feedback.
5. The fifth and the last level of ignorance is meta-ignorance. It is when you don't know about five levels of ignorance.

As you can see, ignorance is the opposite of knowledge. The only way to decrease ignorance is to increase knowledge. High level of ignorance, conscious or subconscious, lead to the lack of knowledge and misinterpretation of the problem, and therefore, increasing the change of building a wrong solution:

Eric Evans, the father of DDD, describes the upfront design as locking in our ignorance. The issue with the upfront design is that we do it at the beginning of a project and this time if when we have the least knowledge and most ignorance. It became a norm to make most important decisions about the design and architecture of the software at the very beginning of projects when there is virtually no ground for such decisions available. This practice is quite obviously not optimal. Mary and Tom Poppendieck in their book Lean Software Development (2003, Addison-Wesley Professional) described the term last responsible moment as the moment at which failing to make a decision eliminate an important alternative and, as the term suggests, advise to postpone important decisions. Agile and lean methodologies also help to communicate knowledge more efficient and awareness of ignorance more obvious.

In the article Introducing Deliberate Discovery (https://dannorth.net/2010/08/30/introducing-deliberate-discovery/), Dan North suggests that we realize our position of being on at least the second level of ignorance when we start any project. In particular, the following three risks need to be taken into account:

• A few Unpredictable Bad Things will happen during the project
• Being Unpredictable, these Things are unknown in advance
• Being Bad, these Things will negatively impact the project

To mitigate these risks, Dan recommends using deliberate discovery, that is, seeking knowledge from the start. Since not all knowledge is equally important, we need to try identifying those sensitive areas, where ignorance is creating most impediments. By raising knowledge levels in these areas, we enable progress. At the same time, we need to keep for new troublesome areas and resolve them too; and this process is continuous and iterative.