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:
- 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
- 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.
- 2nd Order Ignorance – Lack of Awareness i.e. I don’t know that I don’t know something.
- 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
- 4th Order Ignorance – Meta Ignorance i.e. I don’t know about the five orders of ignorance
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.
Reference: The Five Orders of Ignorance – Phillip G. Armour from our NCG partner Mark Needham at the Mark Needham Blog blog.
