Latest posts by Glennan Carnie (see all)
- The Rule of Zero - January 15, 2015
- The Rule of The Big Four (and a half) – Move Semantics and Resource Management - January 1, 2015
- The Rule of The Big Three (and a half) – Resource Management in C++ - December 18, 2014
It’s not often you read a paper that has something unique and fresh to say about a topic, and expresses it in a clear and concise way.
Somehow, Phillip Armour’s The Five Orders of Ignorance had eluded me, until I found it referenced in another paper.
It really is an interesting point of view on software development. You can read the paper here.
Armour’s central tenet is software is a mechanism for capturing knowledge. That is, (correct) software is the result of having understood, and formalised our knowledge about the problem we are developing.
Clearly, at each stage of the development process we have different levels of knowledge (or ignorance; the conjugate of knowledge) about our problem. As we move towards delivery our knowledge increases; and our ignorance decreases – hopefully!
A stratified, or layered, model of ignorance gives a good measure of our progress through the development – in some ways a far superior model than the traditional time/artefact/activity–based approach.
Armour’s levels – or orders – of ignorance are as follows:
Zero Order Ignorance is knowledge; something we know and can articulate (in software)
First Order Ignorance is something we don’t know; a question we need an answer to.
Second Order Ignorance are the things we don’t know we don’t know. That is, we don’t even know what questions to ask.
Third Order Ignorance is lack of methodology – we don’t have techniques, tools or processes that can identify and illuminate our lack of knowledge.
Fourth Order Ignorance means we don’t even know there are orders of ignorance!
(In many ways Armour’s work is a far more cohesive version of Donald Rumsfeld’s infamous “Known Knowns” speech.)
Armour’s paper crystallised a couple of very important points to me:
Why requirements analysis is so vital.
For nearly the last decade I have been promoting the importance of requirements analysis as a key part of development. If we understand the problem we are meant to solve – completely and with precision – developing a solution in software is relatively straightforward.
It’s heartening that most engineers are actually pretty good at developing solutions. But they’re not really very good at understanding problems. When people call me in to help with ‘design issues’ it’s most commonly the case they don’t actually understand their problem properly. Usually, I help their ‘design’ skills by doing detailed requirements analysis with them!
I have found the teams that spend most time performing requirements analysis spend the least time designing and debugging and have the most comprehensive and maintainable solutions. This is because their software captures the system knowledge efficiently and their code isn’t riddled with what Armour calls ‘unknowledge’ – irrelevant, or incorrect knowledge about the system captured as code (you know, the stuff that leads to ‘features’!)
What process is all about.
Processes are a technique to give you questions, not answers. I think this upsets many developers (and their managers). Many people want handle-turning solutions: Feed in some customer requirements, crank the handle, and out comes lovely, pristine software.
Unfortunately, but the world doesn’t work like that. If it did, we’d all be replaced by machines (that’s been threatened since the Sixties and it hasn’t happened yet. I’m not holding my breath, either.)
Every software problem is unique and full of those delicious little subtleties that make our jobs as embedded developers so interesting (and yes, you can take ‘interesting’ in the sense of the old Chinese curse!) There is simply no way you can mechanise the behaviours needed to elicit, understand and formalise all the knowledge required to develop a typical embedded system.
Most approaches to software process description assumes software development is a (linear) mechanical process; and the (procedural) transformation of input artefact to output artefact will (somehow) produce working software. Whilst this approach works for other manufacturing processes it cannot deal with the simple fact that software development is about knowledge capture and, well, we often don’t know what we don’t know!
The best processes are those that consist of a set of goals and a corresponding set of methodologies. The goals effectively give you an appropriate set of questions that must be answered before you can continue; the answers to those questions will yield pertinent information about the system.
One could argue the artefacts are supposed to embody the appropriate design questions but engineers are notorious for simply filling in the blanks with banal waffle just so they can move on to the interesting stuff – that is, hacking code (and learning about the system!)