Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
220.127.116.11. Levels of Ignorance
This classification of software and engineering problems is inspired by Phillip Amour's "The Five Orders of Ignorance", published in the Communications of the ACM. Else where on this web site only three orders of ignorance are seriously considered; the zeroth and last orders are considered to be programmer jokes). While Armour is a humorous author, I have altered his terminology in two ways:
- I have replaced the word order (too mathematically specialized) with the word level which is more meaningful to the general reader,
- The words ignorance and knowledge strike me as a bit pretentious outside of computer science, so I try to be more concrete and positive.
The orders of ignorance can be considered comprehensive in the sense that they follow the hierarchy as in Bertrand Russel's Theory of types in logic for avoiding recursive paradoxes.
Phillip Amour linked the second and third levels to software methodologies and processes. Since I was reading [http;//http://greenbay.usc.edu/csci577/spring2006/site/guidelines/index.html] in IEEE at the time, I linked these levels to architecture and risk management.
Unfortunately the Boehm articles are behind the IEEE pay wall here. I will have to dig up my notes and type them in.
I will try to distinguish problems and issues into the following levels (these also map to more fine-grained 18.104.22.168.-Issue Tracker Labels):
- straight-forward questions - an addition of knowledge within the capability of any person competent in the given field (e.g. a junior engineer or programmer)
- architectural questions - questions about how to structure the straight-forward questions above. Generally within the capability of experienced experts in a field (senior engineers and programmers, editor, proof-reader). These are often partially economic questions about which of the many possible architectures will lead to success,
- risk management questions - questions about how many architectural alternatives can be afforded.
Armour argues that higher levels of ignorance are (perhaps exponentially) more expensive. Boehm discusses costs from an architectural, agile/planned development process, and a risk management perspective.