Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

Agile Software Development: A Critical Review

By Scrymarch in Media
Tue Feb 12, 2002 at 07:09:42 PM EST
Tags: Books (all tags)

This short book is full of good ideas for making software projects more successful. The philosophy of software development presented with it is interesting, but incomplete and possibly flawed.

Cockburn[1] sees software development as a language-game, explains his interpretation of this idea, and builds the book from this interpretation. The Agile Software Development Manifesto , a document advocating lightweight methods and signed by various luminaries, is presented in an appendix.

Alistair Cockburn, Addison-Wesley 2002, ISBN 0-201-69969-9


The Manifesto begins:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.

Noteworthy signatories include Kent Beck and Ward Cunningham of Extreme Programming fame, Andy Hunt and Dave Thomas of The Pragmatic Programmer fame, and Cockburn himself. Together they are termed, with cartoonish overstatement, The Agile Alliance.

With the language-game view of the book, though, these values are restated roughly according to three themes - Communication, Skill and Sufficiency.

Are you talking to me?

Chapter 1 begins:
"A fruitful way to think about software development is to consider it as a cooperative game of invention and communication."

It is common sense that project management requires communication, but it gets forgotten nonetheless. The book reviews instances of this - the value of face-to-face communication, the value of teams sitting together, the anti-social requirements of aspects of programming, and the power of strong customer contacts. It also covers newer ground; discussing the ways information flows within and around a team, and in and out of more permanent forms such as whiteboards and documentation. Throughout this the bias is towards informal "sufficient" communication; sufficiency is discussed below.

Plenty of stories are related; some about software and some about everyday communication, showing the unreliability of natural language but pointing out that it seems to work anyway. Stories are used quite well throughout the book. A List of Stories is even provided along with the Contents. As might be expected, the style is chatty and readable. Once a working language-game is established in a team, Cockburn considers it important enough to bring in a consultant ethnographer to report on what is occurring, an intriguing idea.

Some weak generalisations are stated about language, with a few attempts to explain some typical thought-patterns in computer programming terms. This doesn't always work, and sometimes makes assertions argumentatively shaky by mixing up natural and symbolic languages. In the course of two pages a number protocol, shouting the word "Fire" in Japanese, and a grimace are used as if they were the same type of construct. Later he refers to human failure "modes", when all his evidence suggests humans are an analogue, non-modal system. These would be esoteric distinctions, if the difference between symbolic (e.g., a computer system) and non-symbolic (e.g. a muffled laugh) languages and systems weren't the philosophical basis for Agile methodologies.

Cockburn explicitly acknowledges his debt to Wittgenstein , the philosopher who described interpersonal communication as a language-game. An excerpt from a book by Paul Ehn relating this concept to software system design is even included as an appendix. Wittgenstein asserted that a natural language like English had more scope for meaning than could be captured by a simple descriptive protocol. A person can know things without that person being able to explicitly describe them. Wittgenstein states (Ehn also quotes):

"Consider knowing and saying: how many feet high Mount Blanc is - how the word 'game' is used - how a clarinet sounds. If you are surprised that one can know something and not be able to say it, you are perhaps thinking of a case like the first. Certainly not of one like the third."
-- Philosophical Investigations I, statement 78

The useful vagueness of natural language and human interactions is extolled by Cockburn, but he tends to use it throughout the book as rhetorical cover. A common style used is to put forward some examples as paradigm cases and inductively draw a conclusion without further argument. He discusses the impossibility of communication, and then compounds it with too-easy generalisations.

Use the Force, Luke

Judging by this book and the excellent online resources at the Extreme Programming Wiki, skill is of great importance to the Agile Alliance. If software development is a game, then reasoning plays a part, but subconscious skills are crucial.

This belief in subconscious and informal software development skills fits well with the belief in subconscious and informal communication. Humans and computers are good at different things, and the point is emphasised by the book. People are good at looking around (pattern recognition), learning by doing and adapting to new circumstances. People are bad at precisely repeatable and high-discipline activities unless they have a context that demands it of them.

These observations could be taken straight from Confucius or the Old Testament, but in the field of software development they bear repeating. It seems a continual lament that programmers are undisciplined, and if they just followed Quality Process X more closely, better software would be developed. Cockburn asserts software processes should be designed to take advantage of human skills and have mechanisms to account for their foibles. This is common sense, but it improves over much that holds that name by being a self-aware common sense; a deliberately chosen informality. This self-awareness is a valuable part of the Agile worldview, and feeds into the concept of methodology tailoring, discussed further below.

The view of software development - or at least programming and design - as a skill results in a rich source of metaphors. (A belief in metaphors and paradigm cases, rather than theoretic derivation, is also pervasive.) Cockburn's two major comparisons are team based epic poetry writing and rockclimbing. Two appendices are also included on the topic - Programming As Theory Building, a paper by Peter Naur, and The Book Of Five Rings, a ruthlessly abridged text by Musashi, a 17th century samurai warrior. Looking on the Extreme Programming Roadmap, you can discover that software is also much like skiing, driving, flying and cycling. Certain principles underly many fields of endeavour, and it is interesting and worthwhile to read the opinion of experts in other fields and compare them to your own experience. Buildings That Learn, a book on conventional architecture, has become known in the software field for its design insight. Conversely, it seems possible to make metaphors of any two fields, selected at random [2].

All the fields mentioned in this book, though, include a large degree of internalised ability. Despite its title, Programming As Theory Building argues the overwhelmingly critical aspect of a software project is the theory of the system inside the programmer's head, almost irrespective of any code structure or documentation. At its most extreme interpretation, this elevates programming to a kind of mystical ability, albeit one that can be trained.

For training these internalised skills, Cockburn, champion of the informal, strangely turns to a formal taxonomy - Three Levels of Listening or Shu - Ha - Ri. The three levels relate different approaches to teaching and learning as skills improve, and are treated in the User Interface world as beginner, intermediate, and expert users. Beginners have more reliance on rules; experts are able to treat them as guidelines. This concept is introduced early and used throughout the book.

As someone with little ability at any of the internalised skills used as metaphors, I find the focus on them strangely unintuitive. I can ride a bike well enough, but my experience of programming seems different in type, not just level, to that of cycling. Many of the metaphors rely on exactly this kind of introspective comparison.

Shu - Ha - Ri comes from Aikido, but the categories also seem to correspond to apprenticeship, journeyman and master categories among European medieval craftsman. Cockburn explicitly attacks the term "software engineering":

"Confusing the act of doing engineering work with the outcome of doing engineering work is a common mistake ... The act of doing engineering work is the ill-defined creative process the industrial engineer goes through to invent the manufacturing plant design".

In other words, the act of engineering is like a craft. The book eschews the term as a confusing one, preferring "game".

Cockburn's view of software as a co-operative game of invention and communication is useful, but on those terms the closest game relative is nothing so hip and extreme as rockclimbing samurai swordsmen. The closest relative to software development is a fantasy roleplaying game.

Compare these statements:
Thus, the values of each group contribute to their proper functioning, and the differences are necessary for the proper functioning of the total organization, even though they clash.

In choosing which characters to include in the party, it is wise to include a variety of classes.

The first is from Agile Software Development, and the second is from the Champions of Krynn Adventure Journal. The comparison is not even new, but seems to occur spontaneously wherever programmers gather. In Cryptonomicon, Neal Stephenson, keen observer of people in technical professions, spends over a page letting the main character mull over his role as a Unix admin dwarf amongst Humanities hobbits [3]. The impression is compounded by Cockburn's constant references to Level 1 or Level 2 listeners. (What if I want to Dual Class?)

So, these game comparisons can be useful, but they are by and large being used already. Programmers need only the slightest encouragement to think of themselves as mystically powered creatures having a series of software related adventures, and yet software development still needs improvement. They still skip past talking to the townsfolk and straight to exploring the dungeon, missing critical clues, and the reinforcement of programmer prejudice the game concept provides is little help.

Say When ...

The game view advocated by the book does lead naturally to the concept of sufficiency. For Cockburn, there are two goals for the software development game. The primary goal is delivering a working system. The secondary goal is establishing an advantageous position for the next round of the game. The worth of a development activity is measured by its contribution to these goals, and an activity is only performed while it contributes to these goals. Documentation or intra-team work products needn't be complete, just sufficient. This is related to YouAintGonnaNeedIt, an Extreme Programming principle.

In the later and most concrete chapters of the book, techniques for determining sufficiency in different projects are discussed. Taxonomies for software projects and templates for methodology design are presented. The emphasis is very much on tailoring software processes to a project team, often from a seed that has worked elsewhere. Again, considering the book's emphasis on complex, implicit human interactions, the presentation of the taxonomies is strangely doctrinaire. "What you write for each box will vary, but the names of the elements won't," it states of the general project breakdown, as if Cockburn had discovered a periodic table for project management.

These categories seem fair enough, but particularly useful is his table relating project criticality and number of team members to the weight of the methodology used. This is presented together with a number of design principles as caveats. It is in this area that Cockburn's experience with software projects and use of examples is most welcome. He wonderfully dismembers the cant that can be associated with following software processes. If software gets delivered without the things you "should" do, why are these embellishments in the process at all?

The bias that methodology designers bring to their methodologies is also analysed. Cockburn states his own biases quite straightforwardly, and presents the Crystal Family of methodologies, which he designed. It is revealing that these methodologies have been tried only on smaller and less critical projects, and to his credit that it is stated up front. The book also points out that all established software methodologies were used successfully by their designers. Does Kent Beck perform Extreme Chequebook Balancing?, he asks, intriguingly.

The sufficiency theme is weakest where it once again plays to programmer prejudices. The book does flag elements of different methodologies that maintain quality standards - proofs and statistical testing for Cleanroom; unit tests and pair programming for Extreme Programming (though more time is devoted to Extreme Programming). It is easy, though, to imagine sufficiency being invoked to justify behaviour that is not "sufficient", just dodgy. The topic is broached - one story telling of "Just Never Documentation" - and dodginess does jeopardise the next round of the Cockburn's software game, but the admonitions are mild.

Some conclusions

This is a long review because this short book is not just a useful guide. It comes wrapped around a manifesto, and packed with vague bold philosophical assertions about the nature of software development. The vagueness is partially due to chattiness, but it's also due to a bad structure. The Preface states the book is written in a "whodunit" style. It shouldn't have been. A technical document should state its main message up front and continually. The Agile Software Development Manifesto is included as the first appendix; it should have been included as the first chapter. Cockburn is actually too good a technical writer to keep the ending a mystery, but the chosen structure bends his prose out of shape. He has to sneak up to key themes instead of stating them straightforwardly, making him sound like a salesman asking a leading question. He repeats examples instead of repeating principles. Some of the stories seem contrived. This combines with heavy use of appendices and quotes to make the book seem padded - and it's a short book. The Agile community have made excellent use of Wikis, but this book reads at times like a Wiki, or a speech, and this medium mismatch jars.

Alistair Cockburn could have written a book of useful anecdotes about and techniques for developing software. By using rhetorical hand waving to tie these into a theory of lightweight software development, he has weakened Agile Software Development as a practical text and a theoretical framework.

[1] Pronounced Koh-burn, incidentally.

[2] For fans of the (British) Fast Show , particularly - Writing software is much like making love to beautiful woman ...

[3] Monograph for the alert reader: "The Contemporaneous Emergence Of Fantasy Role-Playing Games and the Software Profession"


Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure


My software is
o Agile 5%
o Extreme 11%
o Rational 2%
o Pragmatic 13%
o Formal 2%
o Open 11%
o Vapour 27%
o Crunchy 25%

Votes: 36
Results | Other Polls

Related Links
o Agile Software Development Manifesto
o Alistair Cockburn
o Addison-We sley 2002, ISBN 0-201-69969-9
o Kent Beck
o Ward Cunningham
o Extreme Programming
o The Pragmatic Programmer
o Wittgenste in
o Philosophi cal Investigations
o Extreme Programming Wiki
o skiing
o driving
o flying
o cycling
o Buildings That Learn
o Three Levels of Listening
o Cryptonomi con
o Neal Stephenson
o YouAintGon naNeedIt
o Fast Show
o Also by Scrymarch

Display: Sort:
Agile Software Development: A Critical Review | 7 comments (6 topical, 1 editorial, 0 hidden)
Alistair Cockburn (1.41 / 24) (#1)
by Defect on Tue Feb 12, 2002 at 01:25:51 PM EST

Heh. Cockburn. rofl.
defect - jso - joseth || a link
Cockburn (none / 0) (#6)
by Gully Foyle on Wed Feb 13, 2002 at 08:38:58 AM EST

The ck is usually silent, so it's pronounced Coburn.

If you weren't picked on in school you were doing something wrong - kableh
[ Parent ]

Don't know what to think (4.28 / 7) (#2)
by speek on Tue Feb 12, 2002 at 02:06:55 PM EST

If the book is half as confusing as this review, then it's definitely not a good book. References to Wittgenstein and language-game theories? Was that actually in the book? Yegads.

Personally, I think the ideas of extreme programming are very useful. I would like to work in a group that used such processes. But, they're simple, common sense ideas - not GUT's of software development.

al queda is kicking themsleves for not knowing about the levees

Extreme Programming (4.00 / 1) (#4)
by Neuromancer on Tue Feb 12, 2002 at 05:04:34 PM EST

I actually work as part of a team that uses UML quite heavily, and has adapted some of the ideas from Extreme Programming to our process. That said, I think that this book touches on something quite different from what is discussed in Extreme Programmign, so there is probably something to be gained from both sources.

[ Parent ]
Confusing (5.00 / 1) (#5)
by Scrymarch on Wed Feb 13, 2002 at 08:04:10 AM EST

If the book is half as confusing as this review, then it's definitely not a good book.

If you follow the flow, it's not a difficult book to read. It's when I tried to think through the implications of his sweeping statements I started scratching my head.

References to Wittgenstein and language-game theories? Was that actually in the book? Yegads.

No, I made it up to slur Mr Cockburn's good name :)

I don't think the Wittgenstein references are bad in themselves. Philosophical ideas eventually filter through to less abstract fields of endeavour, and attempting to apply them to computing is fair enough, ~50 years after they were first written.

I would say such ideas shouldn't be introduced without being able to back them up with some rigour.

[ Parent ]

Media? (late editorial) (4.00 / 2) (#7)
by Scrymarch on Wed Feb 13, 2002 at 10:00:28 AM EST

Ok, the resectioning to Books seems fair, but Media? Do all reviews go there? Technology::Books seems more sensible.

I know, I know, it's fairly academic.

Agile Software Development: A Critical Review | 7 comments (6 topical, 1 editorial, 0 hidden)
Display: Sort:


All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!