Mark Needham

Thoughts on Software Development

The Five Orders of Ignorance – Phillip G. Armour

with 3 comments

While trawling the comments of Dan North’s ‘Deliberate Discovery‘ post I came across an interesting article written by Phillip G. Armour titled ‘The Five Orders of Ignorance‘.

The main thing I took from the article is that the author uses the metaphor of software as a ‘knowledge acquisition activity’ for which he then defines five orders of ignorance that we can have in our attempts to acquire that knowledge.

These are as follows:

  1. 0th Order Ignorance – Lack of Ignorance i.e. I know how to do something and can display by lack of ignorance with some sort of output
  2. 1st Order Ignorance – Lack of Knowledge i.e. I don’t know something but I know that I don’t know how to do it and I know what I need to learn in order to be able to do it.
  3. 2nd Order Ignorance – Lack of Awareness i.e. I don’t know that I don’t know something.
  4. 3rd Order Ignorance – Lack of Process i.e. I don’t know a suitability efficient way to find out I don’t know that I don’t know something
  5. 4th Order Ignorance – Meta Ignorance i.e. I don’t know about the five orders of igorance

Armour points out that the biggest problems when building any system are 2nd and 3rd order ignorance

We can reduce these types of ignorance by having people on the team who have experienced similar situations before and therefore don’t have as much ‘lack of awareness’ as other people who haven’t experienced the same situations.

On the majority of projects that I’ve worked on the main source of ignorance for us has often been around the politics within the organisation.

Most of the developers I work with tend to be quite straight forward in their communication which often isn’t the best style of communication when working with people from another ‘vendor’ or from the client.

I think you do become better at dealing with these situations after you’ve come across them a few times although from my observations each situation has played out a little differently even if the underlying reasons for the human behaviour were the same.

A few months ago Toni wrote a blog post about the way that he works at Forward in which he describes how they don’t have a need for several of the ‘agile practices’ often used on teams.

I’ve also been questioning the point of several of them as it feels like we sometimes just dogmatically follow a practice because that’s what we’ve always done.

Thinking about it from the angle of ignorance I’m now more inclined to believe that the intention of the practices is to help us reduce our ignorance in some way:

  • Stand-up: Helps to reduce the ignorance that people have about what others are working on and whether someone else can help us reduce our own ignorance in some way
  • Retrospective: Helps to reduce our ignorance of how to work more effectively in a team in the context we’re in
  • Writing tests: Helps to reduce someone else’s ignorance about what a piece of code is supposed to do when they come across it. Also provides protection around our ignorance of what we might break by changing code

From what I know about Forward it seems like people would have less ignorance than you might have if you were working as a consultant in a big bureaucratic organisation.

Of course the fact that they only hire very strong developers presumably also means that their technological ignorance is also reduced and it now makes more sense to me how they’re able to work effectively with such a stream lined process.

I do think it still makes sense to question the practices we’re using and constantly assess whether they are actually helping us to reduce our ignorance.

If not then we might as well use the time to do something else.

These are the main two things that came to mind for me while reading the article but I’m sure there are other things to be gained from it.

Armour has also written another article titled ‘The Nature of Software and the Laws of Software Process‘ in which he expands on the orders of ignorance further.

Written by Mark Needham

January 26th, 2011 at 6:08 pm

  • Pingback: Tweets that mention The Five Orders of Ignorance – Phillip G. Armour at Mark Needham -- Topsy.com

  • Phil Armour

    Someone cued me in on this article, so I thought I’d add an additional $0.02′s worth.
    Your point about the main source of ignorance being “politics” is an interesting one. While acquiring the knowledge of the system (customer requirements, design architecture, platform interaction and the like) is the most obvious kind of knowledge one has to acquire to build a system there are many other kinds. Some are quite obvious and quite time consuming: the knowledge of how to (a) plan the project and (b) replan the project when (a) [and (b)] doesn’t work is one that most people get. Well, most project managers anyway. However, internal organizational skills come into play here too. If you have a great team, a firm grasp of requirements, a solid development methodology, and comprehensive knowledge of the development and target environment, but you don’t know how to effectively compete with rival projects for funding it will all come to naught.

    Acquiring “political” knowledge (and here I include the *effective* application of said knowledge as being part of said knowledge) is not something that gets embedded into the delivered system in the way that, say, knowledge of customer requirements is embedded in into the system. But it is necessary nonetheless. Of course, planning knowledge does not get embedded into the system either.

    In the entire spectrum of things-that-must-be-learned to build and deliver the packaged knowledge we call a software system some knowledge is system-intrinsic (eg. requirements), some is optional/conventional (eg. design methods, variable naming conventions), some operates on people (eg. team stuff), some operates on the environment (eg. CM), and some operates on the host organization (eg. that would be politics). There are more…

    We know how lapses in intrinsic systems knowledge manifest themselves–they are what we call “defects” (an exposed bug is a system’s way of telling us there is something we don’t know and we are not as smart as we think we are). It is interesting to consider how a lapse in (say) political knowledge manifests itself within the system, within the project, within the organization and within peoples’ lives.

  • Pingback: Testastic