Customer Reviews

The Laws of Software Process: A New Model for the Production and Management of Software

5 star:		(4)
4 star:		(0)
3 star:		(1)
2 star:		(0)
1 star:		(0)

 

 

Some background for those who don't already know of Phil's work and his recurring column in CACM: One of the main premises of the book is that software is not a "product" in the usual production-oriented sense of the word, but that software is really a medium for capturing executable knowledge. He then uses this to derive that software is therefore not a product-producing activity but rather a knowledge creating and knowledge acquiring activity.

He then talks a little bit about the "Five orders of ignorance" and how, if software development is a knowledge acquiring activity, then it is also ultimately an "ignorance reduction" activity whereby we progressively reduce our ignorance of what the system is, what it needs to do, how it needs to do it, and how we need to do it and manage it.

Anyway - there is a lot more other GREAT stuff in the book (including the actual laws of software process as promised by the title of the book), but that should be enough background for the sections I'm about to summarize below...

Pages 97-159 are devoted to Agility and Agile methods. Chapter 6 is entitled "The Advent of Agile" and Chapter 7 discusses "Agile and the Orders of Ignorance" in detail. The sections and subsections for Chapter 6 are:
> It Has Always Been Agile
> -- Test Phases with Embedded Lifecycles and Test Phases
> -- The "Construct" Phases also have Feedback
> -- The Feedback Activities Generate Feedback Activities
> The Problems of "Big" Process
> Agile Methods
> -- Change is Expected
> -- Feedback is Managed
> -- Stepwise Development
> -- Human Factors
> -- Customer-Centric
> -- Agile is Event-Driven
> Extreme Programming (XP)
> Code Science
> Crystal Methods
> Scrum
> Dynamic Systems Development Method (DSDM)
> Feature-Driven Development (FDD)
> Lean Development
> Adaptive Software Development (ASD)
> Why Agile? Why Now?

The section "Agile is Event-Driven" looked interesting to me because I am accustomed to hearing agile described as feature-driven. So I took a further look and it was indeed interesting to read:

> "The primary characteristic of Agile lifecycle models is that they tend to be more event-driven than the product-production or manufacturing-influenced models. More correctly, they are driven more by what is actually learned than by what is expected to be learned. Agile projects are more responsive to what is really happening than by what was expected to happen....

> "On Agile projects, the work being done at any point in time is a function of what has been learned through the project up until that point in time. This does include the starting points of the expected plan, early contracted deliverables, and probable design approach. But it also includes the reaction to changes in the expected plan, marketplace or customer-driven modifications to the requirements, the evolution of different design alternatives, and the ever-unfolding and continuous acquisition of knowledge that comes from building a system....

> "The fact that older lifecycle management models are not sufficiently agile is one of the biggest causes of grief and failed expectations in software development. When we use models and mindsets that are rigid and deterministic to manage an activity that is fluid and variable, it is not surprising that people get disappointed."

The rephrasing of the principles (not values, but principles) of the agile manifesto as Phil describes them is also very interesting to me:
> INTRINSIC VARIABILITY:
> -- Things will change, deal with it.
> LIMITS OF PRECOGNITION:
> -- We cannot know everything in advance.
> CONSTRUCTIVE FEEDFORWARD:
> -- The act of trying to build something has the potential for changing key characteristics of what we are trying to build.
> CONTEXTUAL POSITIONING:
> -- Sometimes we need to acquire some knowledge to know what other knowledge we need to acquire.
> CONSTRUCTIVE POSITIONING:
> -- Sometimes we need to build things in order to find out how to build things.
> PERSPECTIVE BLINDNESS:
> -- One person looking at a problem cannot see what he or she cannot see.
> EXECUTABLE VALIDITY:
> -- Until we have made knowledge execute, we cannot assert that we have developed executable knowledge.
> KNOWLEDGE DISCOVERY IS ANTHROPOMORPHIC:
> -- The discovery of knowledge is a human activity that is primarily a function of the collective human thought processes and human understanding
> KNOWLEDGE DISCOVERY IS A FUNCTION OF OUR STATE OF MIND:
> -- It is compromised by people being tired, dispirited, and demotivated.
> KNOWLEDGE IS UNDIVIDABLE:
> -- Large collections of related knowledge /cannot/ be fully understood by breaking them into pieces and parceling them out to different people.
> KNOWLEDGE IRRUPTION:
> -- We can only expose knowledge in an environment that that contains the knowledge
> KNOWLEDGE COMPARISONS:
> -- The only way to assert validity of knowledge is to compare against another source of knowledge
> CUSTOMER ARBITRATION:
> -- The only and final arbiter of whether the executable knowledge is useful and valuable in allowing the customer to more effectively operate in the customer's environment is the customer executing that knowledge in the customer's environment.
> KNOWLEDGE STRUCTURE INTEGRITY:
> -- It is necessary to maintain the structural integrity of the knowledge representation as new knowledge is discovered.
> OCCAM'S DESIGN RAZOR:
> -- The simplest design that suffices to provide value to the customer is the best design to use.

What can I say? I like this guy! :-)

This book develops the idea that the problem with the way we develop systems, software, and apps is that we think of software as a product. The author argues that that's part of what gets us into trouble. Think of the very-public software failures that led to massive business failures (and billions of dollars down the tubes): Denver Airport, London's TAURUS stock exchange, and the CONFIRM airline reservation project (forget the dot coms for now). This book proposes an alternative idea: Software must be thought of as a medium for storing knowledge. If you fail to embed the relevant and oft dispersed knowledge in a software application, that is the making of a fialure. The author then draws comelling linkages between this idea and the role f software processes, methodologies, and the norms that dominate the industry. The book is written in a very coherent way and unlike most technology books. It's actually fun to read. Think of it as the next delightful book to appear after Hal Varian's 1999 bestseller "Information Rules." The ideas that the author develops appeared in thier preliminary form in several columns in Communications of the ACM. Here, those ideas are extnesively developed. The sixty dollar price tag might dissuade some, but a quick scan in the library is going to be sufficient to convince anyone interested in software development and IT management about the value of giving this book a permanent spot on thier bookshelf. Strongly recommended. Must have.

I like his theory that there are five "Orders of Ignorance with regard to "knowledge". Take e.g. the "Second Order Ignorance" (2OI): "I have 2OI when I do not know that I do not know something" and "3OI" defined as: "I have 3OI when I do not know a suitable efficient way to find out that I do not know that I do not know something".

And from that starting points Armour analyses (Software) projects and which Order of Ignorance they fall into - or better - their participants. It's quite an eye opening way to think about my attitude towards new projects, to check (probably afterwards) which Order of Ignorance I displayed. But the rest of the book leaves a strange feeling of "thinnness". To many recapitulations , to much stuff I have already read elsewhere (Gerald Weinberg or Alistair Cockburn cross my mind). Not that they are so much better but if you - as me - have read them first, they seem much fresher much more original. So I am tempted to say to Philip Armour: "Everything has been said, but not yet by everyone".

But to be fair this book is a collection articles previous published as a regular column in the Communications of the ACM, so some repetition and some superficality might be due to the restraints of writing such a column.

Anyway the book is fun to read and you find the occasional interesting insight or quote, like e.g. "'Organizations should create an approved documented process' [...] sounds to me like a license to kill trees".

While this book is focused on the process of developing software, the main concepts are applicable to almost any kind of useful work; especially knowledge work. The author very deftly introduces the idea of orders of ignorance; a means by which you can evaluate a given problem in terms of what you know and don't know, and don't know that you don't know.

The author's extensive software experience shows in this book that offers some thought-provoking ideas and approaches for software development. Mr. Armour also makes some very interesting observations on the role of process, models, and teams in the context of developing innovative software systems in the current information technology age.