T he Business of Software
Phillip G. Armour

The Five Orders of Ignorance
Viewing software development as knowledge acquisition andignorance reduction.

PAUL ZWOLAK

I

n my first column (Aug. 2000,
p. 19), I argued that software is
not a product, but rather amedium for the storage of knowledge. In fact, it is the fifth suchmedium that has existed since thebeginning of time. The otherknowledge storage media being, in
historical order: DNA, brains,
hardware, and books. The reason
software has become thestorage medium of
choice is that knowledge
in software has been
made active. It hasescaped the confinement and volatility ofknowledge in brains; it
avoids the passivity ofknowledge in books; it
has the flexibility andspeed of change missing
from knowledge in
DNA or hardware.
If software is not a
product, then what isthe product of ourefforts to produce software? It is the knowledge contained in thesoftware. It’s rather easy
to produce software. It’smuch more difficult to
produce software thatworks, because we haveto understand themeaning of “works.” It’s
easy to produce simple

software because it doesn’t containmuch knowledge. Software is easier to produce using an application
generator, because much of theknowledge is already stored in theapplication generator. Software iseasy to produce if I’ve already produced this type of system before,
because I have already obtained thenecessary knowledge.

So, the hard part of building
systems is not building them, it’sknowing what to build—it’s inacquiring the necessary knowledge.
This leads us to another observation: if software is not a productbut a medium for storing knowledge, then software development is
not a product-producing activity, it
is a knowledge-acquiring activity.

Hacking
It is quite easy to show thatsoftware development is aknowledge-acquisition activity using a slightly exaggerated example. Imagine ahacking project. With hacking, there is no real attempt
to acquire the knowledge
first, the project just hacks
code. As the code is written
and executed (testing may be
too strong a word), there
comes a point where validityof the knowledge in the code
is checked somehow. This
accomplishes two things: it
identifies what in the code is“correct” (the knowledge) andwhat in the code is “incorrect” (what I call “unknowledge”). This unknowledge isoften—somewhat incorrectly—considered to be
defects. From a knowledge
perspective, “unknowledge” isstill knowledge; it just doesn’t
COMMUNICATIONS OF THE ACM October 2000/Vol. 43, No. 10

17The problem arises when we think thecode, rather than the knowledge in thecode, is the product.
apply to this particular system.
Coding continues by strippingout the “unknowledge” code andbuilding on the “knowledge” code.
This continues until the next validation point. This whole activity
repeats until the system is built.
Note that the activity of coding is
simply the mechanism that isbeing used to capture the knowledge (and unknowledge). Most
time is actually spent in deriving
these two forms of knowledge, andthen identifying and separating
them.
At the end of this hacking activity, having written a lot of code,
we are left mostly with “knowledge” code. One could legitimately
argue that if this system can successfully pass all tests we can throwat it, it does, ipso facto, contain all
the necessary knowledge. However,there are a few further observations
we can make:• Unless great care is taken to
remove all traces of the “unknowledge” from the code, some legacy
will remain. That is, the program
will be contaminated by the footprints of the “unknowledge.”
These footprints will be extra
states, switches, declarations,loops, and so forth, that supported the incorrect assumptions,but were not fully removed. The
code may work, but it’s not“good” code. So, while the final
product does contain the necessary knowledge, it also contains
18

the remains of the journey to findthat knowledge.
• While we are acquiring two different kinds of knowledge (whatworks and what doesn’t), we are
only saving one kind. The “whatdoesn’t” is simply thrown away.
• The hacking approach does notwork well if there is a significant
likelihood of later knowledge
invalidating earlier knowledge.
When this happens, there will beenormous amounts of backtracking in order to rework the system.
The problem is that the final
product is contaminated with thelegacy of the process used to build
it. Perhaps the developer knows
this and understands what shouldhave been redesigned. But no one
else does, and in a year’s time, thedeveloper will have forgotten why
it looks the way it does. For thisreason, code is a write-only knowledge store.
It’s evident from this example
that the real job is not writing thecode, or even building the system—it is acquiring the necessary
knowledge to build the system.
When hacking, we use the activityof building the system (or rather
attempting to build the system) as
our mechanism for understanding
what the system has to do. Code issimply a by-product of this activity. The problem arises when we
think the code, rather than theknowledge in the code, is the
product. Then we are tempted to

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

ship the code as is. What weshould do, of course, is rewrite thecode so it cleanly represents theknowledge after the hacking stage. If
we have done a good job of capturing what we have learned byhacking the code, writing it again
should be straightforward andrather quick. The act of doing thisintentionally is called prototyping.
As a development life-cycle
model, prototyping acknowledges
that our job is not to build a system, but to acquire knowledge. We
don’t expect to get a functioning
system the first time out when
prototyping. What we do expect
to get is (some of) the knowledge
needed to build the system. And
we use prototyping particularly
when we don’t know in advance
what kind of knowledge we mightneed or there is a likelihood oflater knowledge modifying earlier
knowledge.
So if our job is to acquire
knowledge, what can we assert
about the knowledge we must
gain? For everything we know, we
also have a certain amount of ignorance. Ignorance being simply theother side of the knowledge coin.
If we view systems development as
the acquisition of knowledge, we
can also view it as the reduction or
elimination of ignorance. We
would hope that, at the end of the
project, we are less ignorant than
we are at the start. So what kindsof ignorance might we exhibit?

The Five Orders of
Ignorance
Based upon what we know andwhat we don’t know, we can classify our ignorance into strata or
layers. These I call the “Five
Orders of Ignorance.” They can be

T he Business of Software

helpful in understanding what isneeded to reduce our ignorance
and build a system that works.
They also help explain some of theartifacts of the software development environment, and some ofour behaviors working in this environment.
Since we are computer folk, westart counting from zero, rather
than one. And so we’ll apply thisto the Orders of Ignorance:
0th Order Ignorance (0OI)—
Lack of Ignorance. I have 0OI
when I know something and candemonstrate my lack of ignorance
in some tangible form, such as bybuilding a system that satisfies theuser. 0OI is knowledge. As an
example, since it has been a hobbyof mine for many years, I have
0OI about the activity of sailing,which, given a lake and a boat, iseasily verified.
1st Order Ignorance (1OI)—
Lack of Knowledge. I have 1OI
when I don’t know something andcan readily identify that fact. 1OI
is basic ignorance. Example: I do
not know how to speak the Russian language—a deficiency I could
readily remedy by taking lessons,reading books, listening to theappropriate audiotapes, or moving
to Russia for an extended periodof time.
2nd Order Ignorance (2OI)—
Lack of Awareness. I have 2OI
when I don’t know that I don’tknow something. That is to say,
not only am I ignorant of something (for instance I have 1OI), I
am unaware of this fact. I don’tknow enough to know that I don’tknow enough. Example: I cannot
give a good example of 2OI (ofcourse).

3rd Order Ignorance (3OI)—
Lack of Process. I have 3OI when
I don’t know a suitably efficient
way to find out I don’t know that I
don’t know something. This is lackof process, and it presents me witha major problem: If I have 3OI, I
don’t know of a way to find out
there are things I don’t know that I
don’t know. Therefore, I can’tchange those things I don’t knowthat I don’t know into either things
that I know, or at least things I
know that I don’t know, as a step
toward converting the things I
know that I don’t know into things
I know. For system development,
the “suitably efficient” proviso
must be added, since there isalways a default 3OI process available: try and build the system.
Whereupon the customer can berelied on to inform me of all thethings I did not know.
4th Order Ignorance (4OI)—
Meta Ignorance. I have 4OI when
I don’t know about the Five
Orders of Ignorance. I no longer
have this kind of ignorance, andnow, neither, dear reader, do you.

The Five Orders of
Ignorance in System
Development
Each of the Five Orders of Ignorance plays a significant role inbuilding systems:• 0OI: Since 0OI is knowledge,
this is the correctly functioning
element of the system that I
understood and successfully incorporated into the system. When I
have 0OI, I have the answer tothe problem.
• 1OI: These are the known variables, where the presence of thevariables is known, but not theirvalues. When I have 1OI, I havethe question. Usually, having agood question makes it fairly easy
to find the answer.
• 2OI: This is the real problem.
Not only do I not have theanswer I need, I don’t even havethe question. This is where we
start many projects. When we
begin projects, we know, fromexperience there are many things
we have to learn. We just don’tknow what they are. 2OI
explains, for instance, most variation in project estimates and theconcept of “contingency” (toallow for things we haven’t
thought of). 2OI also explains thefamous “90% complete program
syndrome,” where a programmer
asserts with conviction that he or
she is 90% complete, sometimes
for months on end. The programmer is not “lying,” but certainly is
not correct. Basically the programmer doesn’t know how complete he or she is. Why? Becauseof 2OI, the programmer doesn’tknow what the programmer doesn’t know. 2OI also accounts forrework cycles, late-phase“gotchas,” and what project manager and author Fred Brooks calls“second system effect.”• 3OI: Coupled with 2OI, 3OI
presents a real danger (I don’t havea way to resolve my lack of knowledge during the available time Ihave). Personally, I think all software development methodologies
are actually 3OI processes, whose
main job is to show the areas ofthe product or process, or where I
lack knowledge. There is an
important thing to note—theanswer I am looking for cannot be

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

19

T he Business of Softwarein the methodology. With few
exceptions, methodology simply
gives me a syntax in which toframe the question and a discipline
for identifying those areas where I
might have 2OI. But it can’t knowwhat I’m trying to do. The answer
must come from elsewhere.
• 4OI: This is probably not too
much of an issue, though I’ve
found thinking of process this way
helps. We’ve found ways to compensate for our orders of ignorance, like the use of contingency
for 2OI. I added 4OI to thismodel mostly because knowledge
is inherently recursive.
The critical levels seem to be 2OIand 3OI. I view most of our work
to be the reduction of 2OI, andthe development and use of all
software and systems methodologies as being 3OI processes. The
job of a 3OI process is to illuminate our 2OI. The application of

3OI to 2OI generates either 1OI
or more rarely 0OI—the process
either gives us the answer (0OI) or
more commonly, it gives us thequestion (1OI). This is one of the
major purposes of process and is
the major role of methodologies
and modeling.
The critical point here is thatthe application of 3OI processes(methodologies and process) does
not give the answer; it gives me
the question. As a business model,
we have been looking to thesetools for the wrong thing. We
expect them to provide us withanswers, and that’s not what theydo. It is very frustrating to expect
an answer and instead get a question; to use a methodology to
reduce the amount of work, andapparently increase it; or to conscientiously apply a process only tohave it tell us just how little weactually know. But that is the reality of the software development

business. A functioning system isthe by-product of the activity offinding things out. The working
system is the proof that I have theknowledge. Looked at pragmatically, the goal is to resolve ourorders of ignorance to 0OI. We
spend most of our energies acquiring knowledge. Since finding theanswer to 1OI is straightforward,
we must be spending most of our
production energy on 2OI, andmost of our process energy on
3OI. We can use the Orders of
Ignorance to categorize what weknow, and what we don’t know, toestimate the likelihood of what we
don’t know we don’t know, and toassign to process and methodology
their true place in the order ofthings. cPhil Armour (armour@corvusintl.com) is avice president and senior consultant at Corvus
International Inc, Deer Park, IL.
© 2000 ACM 0002-0782/00/1000 $5.00

Coming Next Month in theNovember Issue ofCommunications
A special section on the latest advances inultra-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, therole of paper in the digital age, online shopping behavior, theimplications for virtual organizations, and politics and technology inthis month of election fever.

20

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