T he Business of Software

Phillip G. Armour

The Five Orders of Ignorance

Viewing software development as knowledge acquisition and
ignorance reduction.

I
n my first column (Aug. 2000, software because it doesn’t contain So, the hard part of building
p. 19), I argued that software is much knowledge. Software is eas- systems is not building them, it’s
not a product, but rather a ier to produce using an application knowing what to build—it’s in
medium for the storage of knowl- generator, because much of the acquiring the necessary knowledge.
edge. In fact, it is the fifth such knowledge is already stored in the This leads us to another observa-
medium that has existed since the application generator. Software is tion: if software is not a product
beginning of time. The other easy to produce if I’ve already pro- but a medium for storing knowl-
knowledge storage media being, in duced this type of system before, edge, then software development is
historical order: DNA, brains, because I have already obtained the not a product-producing activity, it
hardware, and books. The reason necessary knowledge. is a knowledge-acquiring activity.
software has become the
storage medium of Hacking
choice is that knowledge It is quite easy to show that
in software has been software development is a
made active. It has knowledge-acquisition activ-
escaped the confine- ity using a slightly exagger-
ment and volatility of ated example. Imagine a
knowledge in brains; it hacking project. With hack-
avoids the passivity of ing, there is no real attempt
knowledge in books; it to acquire the knowledge
has the flexibility and first, the project just hacks
speed of change missing code. As the code is written
from knowledge in and executed (testing may be
DNA or hardware. too strong a word), there
If software is not a comes a point where validity
product, then what is of the knowledge in the code
the product of our is checked somehow. This
efforts to produce soft- accomplishes two things: it
ware? It is the knowl- identifies what in the code is
edge contained in the “correct” (the knowledge) and
software. It’s rather easy what in the code is “incor-
to produce software. It’s rect” (what I call “unknowl-
much more difficult to edge”). This unknowledge is
produce software that often—somewhat incor-
works, because we have rectly—considered to be
PAUL ZWOLAK

to understand the defects. From a knowledge

meaning of “works.” It’s perspective, “unknowledge” is
easy to produce simple still knowledge; it just doesn’t

COMMUNICATIONS OF THE ACM October 2000/Vol. 43, No. 10 17

 ship the code as is. What we
The problem arises when we think the should do, of course, is rewrite the
code so it cleanly represents the
code, rather than the knowledge in the knowledge after the hacking stage. If
we have done a good job of cap-
code, is the product. turing what we have learned by
hacking the code, writing it again
apply to this particular system. the remains of the journey to find should be straightforward and
Coding continues by stripping that knowledge. rather quick. The act of doing this
out the “unknowledge” code and • While we are acquiring two dif- intentionally is called prototyping.
building on the “knowledge” code. ferent kinds of knowledge (what As a development life-cycle
This continues until the next vali- works and what doesn’t), we are model, prototyping acknowledges
dation point. This whole activity only saving one kind. The “what that our job is not to build a sys-
repeats until the system is built. doesn’t” is simply thrown away. tem, but to acquire knowledge. We
Note that the activity of coding is • The hacking approach does not don’t expect to get a functioning
simply the mechanism that is work well if there is a significant system the first time out when
being used to capture the knowl- likelihood of later knowledge prototyping. What we do expect
edge (and unknowledge). Most invalidating earlier knowledge. to get is (some of) the knowledge
time is actually spent in deriving When this happens, there will be needed to build the system. And
these two forms of knowledge, and enormous amounts of backtrack- we use prototyping particularly
then identifying and separating ing in order to rework the system. when we don’t know in advance
them. what kind of knowledge we might
At the end of this hacking activ- The problem is that the final need or there is a likelihood of
ity, having written a lot of code, product is contaminated with the later knowledge modifying earlier
we are left mostly with “knowl- legacy of the process used to build knowledge.
edge” code. One could legitimately it. Perhaps the developer knows So if our job is to acquire
argue that if this system can suc- this and understands what should knowledge, what can we assert
cessfully pass all tests we can throw have been redesigned. But no one about the knowledge we must
at it, it does, ipso facto, contain all else does, and in a year’s time, the gain? For everything we know, we
the necessary knowledge. However, developer will have forgotten why also have a certain amount of igno-
there are a few further observations it looks the way it does. For this rance. Ignorance being simply the
we can make: reason, code is a write-only knowl- other side of the knowledge coin.
edge store. If we view systems development as
• Unless great care is taken to It’s evident from this example the acquisition of knowledge, we
remove all traces of the “unknowl- that the real job is not writing the can also view it as the reduction or
edge” from the code, some legacy code, or even building the sys- elimination of ignorance. We
will remain. That is, the program tem—it is acquiring the necessary would hope that, at the end of the
will be contaminated by the foot- knowledge to build the system. project, we are less ignorant than
prints of the “unknowledge.” When hacking, we use the activity we are at the start. So what kinds
These footprints will be extra of building the system (or rather of ignorance might we exhibit?
states, switches, declarations, attempting to build the system) as
loops, and so forth, that sup- our mechanism for understanding The Five Orders of
ported the incorrect assumptions, what the system has to do. Code is Ignorance
but were not fully removed. The simply a by-product of this activ- Based upon what we know and
code may work, but it’s not ity. The problem arises when we what we don’t know, we can clas-
“good” code. So, while the final think the code, rather than the sify our ignorance into strata or
product does contain the neces- knowledge in the code, is the layers. These I call the “Five
sary knowledge, it also contains product. Then we are tempted to Orders of Ignorance.” They can be

18 October 2000/Vol. 43, No. 10 COMMUNICATIONS OF THE ACM

 T he Business of Software

helpful in understanding what is 3rd Order Ignorance (3OI)— variables is known, but not their
needed to reduce our ignorance Lack of Process. I have 3OI when values. When I have 1OI, I have
and build a system that works. I don’t know a suitably efficient the question. Usually, having a
They also help explain some of the way to find out I don’t know that I good question makes it fairly easy
artifacts of the software develop- don’t know something. This is lack to find the answer.
ment environment, and some of of process, and it presents me with • 2OI: This is the real problem.
our behaviors working in this envi- a major problem: If I have 3OI, I Not only do I not have the
ronment. don’t know of a way to find out answer I need, I don’t even have
Since we are computer folk, we there are things I don’t know that I the question. This is where we
start counting from zero, rather don’t know. Therefore, I can’t start many projects. When we
than one. And so we’ll apply this change those things I don’t know begin projects, we know, from
to the Orders of Ignorance: that I don’t know into either things experience there are many things
0th Order Ignorance (0OI)— that I know, or at least things I we have to learn. We just don’t
Lack of Ignorance. I have 0OI know that I don’t know, as a step know what they are. 2OI
when I know something and can toward converting the things I explains, for instance, most varia-
demonstrate my lack of ignorance know that I don’t know into things tion in project estimates and the
in some tangible form, such as by I know. For system development, concept of “contingency” (to
building a system that satisfies the the “suitably efficient” proviso allow for things we haven’t
user. 0OI is knowledge. As an must be added, since there is thought of). 2OI also explains the
example, since it has been a hobby always a default 3OI process avail- famous “90% complete program
of mine for many years, I have able: try and build the system. syndrome,” where a programmer
0OI about the activity of sailing, Whereupon the customer can be asserts with conviction that he or
which, given a lake and a boat, is relied on to inform me of all the she is 90% complete, sometimes
easily verified. things I did not know. for months on end. The program-
1st Order Ignorance (1OI)— 4th Order Ignorance (4OI)— mer is not “lying,” but certainly is
Lack of Knowledge. I have 1OI Meta Ignorance. I have 4OI when not correct. Basically the pro-
when I don’t know something and I don’t know about the Five grammer doesn’t know how com-
can readily identify that fact. 1OI Orders of Ignorance. I no longer plete he or she is. Why? Because
is basic ignorance. Example: I do have this kind of ignorance, and of 2OI, the programmer doesn’t
not know how to speak the Russ- now, neither, dear reader, do you. know what the programmer does-
ian language—a deficiency I could n’t know. 2OI also accounts for
readily remedy by taking lessons, The Five Orders of rework cycles, late-phase
reading books, listening to the Ignorance in System “gotchas,” and what project man-
appropriate audiotapes, or moving Development ager and author Fred Brooks calls
to Russia for an extended period Each of the Five Orders of Igno- “second system effect.”
of time. rance plays a significant role in • 3OI: Coupled with 2OI, 3OI
2nd Order Ignorance (2OI)— building systems: presents a real danger (I don’t have
Lack of Awareness. I have 2OI a way to resolve my lack of knowl-
when I don’t know that I don’t • 0OI: Since 0OI is knowledge, edge during the available time I
know something. That is to say, this is the correctly functioning have). Personally, I think all soft-
not only am I ignorant of some- element of the system that I ware development methodologies
thing (for instance I have 1OI), I understood and successfully incor- are actually 3OI processes, whose
am unaware of this fact. I don’t porated into the system. When I main job is to show the areas of
know enough to know that I don’t have 0OI, I have the answer to the product or process, or where I
know enough. Example: I cannot the problem. lack knowledge. There is an
give a good example of 2OI (of • 1OI: These are the known vari- important thing to note—the
course). ables, where the presence of the answer I am looking for cannot be

COMMUNICATIONS OF THE ACM October 2000/Vol. 43, No. 10 19

 T he Business of Software

in the methodology. With few 3OI to 2OI generates either 1OI business. A functioning system is
exceptions, methodology simply or more rarely 0OI—the process the by-product of the activity of
gives me a syntax in which to either gives us the answer (0OI) or finding things out. The working
frame the question and a discipline more commonly, it gives us the system is the proof that I have the
for identifying those areas where I question (1OI). This is one of the knowledge. Looked at pragmati-
might have 2OI. But it can’t know major purposes of process and is cally, the goal is to resolve our
what I’m trying to do. The answer the major role of methodologies orders of ignorance to 0OI. We
must come from elsewhere. and modeling. spend most of our energies acquir-
• 4OI: This is probably not too The critical point here is that ing knowledge. Since finding the
much of an issue, though I’ve the application of 3OI processes answer to 1OI is straightforward,
found thinking of process this way (methodologies and process) does we must be spending most of our
helps. We’ve found ways to com- not give the answer; it gives me production energy on 2OI, and
pensate for our orders of igno- the question. As a business model, most of our process energy on
rance, like the use of contingency we have been looking to these 3OI. We can use the Orders of
for 2OI. I added 4OI to this tools for the wrong thing. We Ignorance to categorize what we
model mostly because knowledge expect them to provide us with know, and what we don’t know, to
is inherently recursive. answers, and that’s not what they estimate the likelihood of what we
do. It is very frustrating to expect don’t know we don’t know, and to
The critical levels seem to be 2OI an answer and instead get a ques- assign to process and methodology
and 3OI. I view most of our work tion; to use a methodology to their true place in the order of
to be the reduction of 2OI, and reduce the amount of work, and things. c
the development and use of all apparently increase it; or to consci-
software and systems methodolo- entiously apply a process only to Phil Armour ([email protected]) is a
vice president and senior consultant at Corvus
gies as being 3OI processes. The have it tell us just how little we International Inc, Deer Park, IL.
job of a 3OI process is to illumi- actually know. But that is the real-
nate our 2OI. The application of ity of the software development © 2000 ACM 0002-0782/00/1000 $5.00

Coming Next Month in the

November Issue of

Communications A special section on the latest advances in

ultra-high-density data storage.

We will also include an array of articles and columns that address

such topics as the Internet and the future of financial markets, the
role of paper in the digital age, online shopping behavior, the
implications for virtual organizations, and politics and technology in
this month of election fever.

20 October 2000/Vol. 43, No. 10 COMMUNICATIONS OF THE ACM