Uncovering Ignorance in Software Development

The Laws of Software Process: A New Model for the Production and Management of Software
Philip G. Armour
Aurerbach
2003
ISBN 0849314895
320 pages, US$59.95

As we already know (but have sometimes forgotten), process is all about drawing from experience to guide current and future work. But when our experiences are insufficient or too varied, there can be no process, so we must struggle forward as best we can. Philip Armour’s The Laws of Software Process reminds us of just that. (As it turns out, he needs 203 pages to do it, not counting the two appendices and the index.)

Armour comes to the subject with a long software development history and two attempts, in an industrial setting, at drafting company-wide software process guidelines. Not unexpectedly, his first document was long on detail and short on applicability, so it languished on engineering bookshelves. A few years later, a more experienced Armour helped produce a second document that was short on detail and, as a result, short on applicability. It, too, languished on bookshelves. Most recently, Armour has been a writing a regular column in the Communications of the ACM, a sister publication of sorts to Computer and IEEE Software. The material in The Laws of Software Process is drawn from his columns (and sometimes reads as such, due to insufficient editing to remove some repetition).

A main premise of the book is that software isn’t a product per se, but rather a medium for storing executable knowledge. It therefore follows that software development isn’t a product-producing activity but a knowledge-creating, knowledge-acquiring activity.

In his book, Armour goes beyond the usual “how to help software developers do things right,” which software process typically addresses. He points out that to better understand software process, we need to better understand the kinds of ignorance—in the true sense of “lack of knowledge”—that we face when software development begins.

In particular, Armour defines five levels of ignorance and then goes on to demonstrate that if software development is a knowledge-acquiring activity, we ought to do our very best at the start to carefully identify the kind of ignorance we face and how to cope with it. Along the way, he discusses such questions as “How should we train software development people?” and, more importantly, “How can we help them learn to do better?”

Armour describes the five levels as

*   Zero order ignorance: Lack of ignorance; that is, knowing something and knowing that you can demonstrate that knowledge.

*   First order ignorance: Lack of knowledge; that is, knowing that you don’t know something, but knowing that you could learn and how you could learn.

*   Second order ignorance: Lack of awareness; that is, not knowing something and not knowing that you don’t know. You are ignorant (unaware) that you have first order ignorance.

*   Third order ignorance: Lack of process; that is, you don’t know how to “discover” whether you have second order ignorance. Practically, this means that no suitably efficient (reasonably time-limited) help is at hand to guide the discovery process. (Of course, we can always fall back on the “build it and see, let the chips fall where they may” mentality, but this kind of practice is clearly untenable in a business context.)

*   Fourth order ignorance: Lack of ignorance about the orders of ignorance. Practically, Armour suggests that this is best interpreted to mean lack of awareness about what software development is really all about (knowledge acquisition and storage).

Middle chapters review various software development process topics, including CMM (Capability Maturity Model), various agile methods, and extreme programming, with these levels of ignorance used to highlight relative strengths and weaknesses.

Clearly, it’s second order ignorance that trips us up. Unfortunately, third order ignorance means that we can’t properly anticipate second order ignorance (because we don’t know how to find out that we lack knowledge that will help us do things right from the start).

Of course, there’s much more in the book (including a rather good chocolate cookie recipe), and it’s also an easy read. At first glance, The Laws of Software Process will most likely interest software processors. But when the levels of ignorance are reinterpreted as different kinds of uncertainty, Armour’s message becomes equally important for project managers.

Paul Freedman is the president of Simlog. Contact him at paul.freedman@ieee.org.