Floundering in Ignorance

One of the most enlightening experiences I had in college was collaborating on a software project in a large group. After struggling with the social dynamics and the difficulty of the project, I learned about a concept described by Philip Armour called the "Orders of Ignorance." This concept provides a framework for understanding difficulties in software development and illuminates the source of our struggles.

Armour explains that in life there are various orders of ignorance. The 0th order is knowing something, or having an answer. The 1st order is awareness of a lack of knowledge, or having a question. The 2nd order is a lack of such awareness, or not even having a question. The 3rd order is not having a way of discovering what is unknown. My group’s main difficulty dealt with the 3rd order of ignorance: we did not know how to proceed once we chose a problem to solve.

Originally, the group leader decided that we would build a product to help system administrators easily view a computer system’s status. We hoped that building an interactive web interface with real-time graphs would enable system administrators to easily identify system-related issues. While we understood the problem we wanted to solve, we could not figure out what information the user would need. We did not know which kinds of data should be displayed together, how to analyze and display the data in a meaningful way, or how to empower the user to dive deeper and inspect the data more thoroughly. The group leader had the best understanding of system administrator needs, but he was often unavailable and ineffective in communicating his desires, leaving our group to flounder.

Ultimately, the group decided that the project was too hard and we switched to one we understood better. Looking back on the experience, I now realize things that we could have done to succeed with the original project. In other words, I no longer have 3rd order ignorance concerning the situation; I know processes we could have used to find questions and figure things out.

First, we should have just started building something. We could have made a simpler version of our product to report at least one piece of the data in real-time. Not only would this have helped us progress in building the product, but it also would have likely given us new ideas about displaying system data. In other words, we should have tried to discover through building. Armour calls this process of resolving 2nd order ignorance hacking. Hacking almost always makes 3rd order ignorance impossible by definition.

The second thing we could have done is to ask for help. If we had just made the connection between our struggles and 3rd order ignorance, this would have solved the problem. We could have sought help from our professor, done more research, or talked to other students who might have had more experience with system administration. Each of these sources might have given us direction.

This experience of applying the orders of ignorance to my situation after I had already failed makes me wish I had understood them better at the time so that my group could have succeeded. While the other project we worked on represented a great learning experience, giving up on the first project leaves me with a bad taste in my mouth. Other software developers should also have an understanding of these principles. This could help companies, open source groups, and programming hobbyists succeed where they might otherwise fail.

(Philip Armour's "Orders of Ignorance" can be found in Appendix B of his book, The Laws of Software Process: A New Model for the Production and Management of Software)