Some interest, much nonsense, and surprisingly dated

Advice and anecdotes for project teams


Alistair Cockburn: Surviving Object-Oriented Projects, 1998, Addison Wesley, ISBN 0-201-49834-0, 250 pages
reviewed by Conrad Weisert, July 2002


Scope and audience

The title is misleading. The book is less about object oriented methodology than about so-called "agile" approaches. Given the author's well-known interest in that topic, that's hardly surprising, but you shouldn't expect a lot of specific wisdom about the impact of object technology on project management.

The intended audience includes:

Surprises and irritations

Condescending tone

Alistair Cockburn continually irritates his audience with condescending put-downs of our professionalism and mature judgment. For example:

Some of that may strike a responsive chord with a few frustrated managers, but Mr. Cockburn's disdain for programmers is sure to offend the experienced professional. A reader who comes to dislike the author will hardly be receptive to the author's advice, even when it's sound.

The most successful writers on I.T. address their audience as respected colleagues with whom they're sharing knowledge. An excellent example is Marty Hall.

Dated claims and anachronisms

In a 1998 book it's startling to encounter assertions:

Such views may have been held in 1992, but by 1998 the novelty had certainly worn off and object-orientation had become firmly established as the mainstream of serious software development methodology on all platforms.

Surviving Object-Oriented Projects was likely created over a long span of time, perhaps a decade. It's hard to imagine this proposition being seriously put forth later than about 1994:

"Smalltalk is becoming the legitimate successor of COBOL for object-oriented applications on the workstation." (p. 59)

Despite the 1998 publication and copyright date the "seventh printing, October 2001" cites as a reference another Addison-Wesley book from 2000. (p.57)

Language biases

Like many others in the so-called "agile community" Mr. Cockburn is a strong partisan of Smalltalk, and a vigorous opponent of C++, the language that a decade ago unseated Smalltalk as the dominant O.O. development tool. He repeatedly warns against the added complexity we take on when we choose C++, citing memory management as a particular C++ pitfall.

Memory management is indeed a notorious source of error in C programming1 but not necessarily C++. Indeed C++ gives the designer the ability to isolate, localize, and tightly control most instances of explicit memory allocation and freeing. Mr. Cockburn failed to recognize the essential 2-tiered nature of programming in any object-oriented language: Some programmers design and build classes while other programmers use those classes to implement applications. The latter, more numerous group can manage quite well with little explicit memory management, sometimes none at all.

Memory management pitfalls aside, it's surprising that a collection of advice on managing object-oriented projects would overlook that central and important distinction.

Mixed advice

Mr. Cockburn presents a strange and frustrating mixture of solid good advice and utter nonsense. A perceptive experienced reader may derive some reassurance and support from the good parts, but similar common-sense guidance is better presented elsewhere.

The sound

Throughout the book the author emphasizes the need to support an organization's first object-oriented projects with strong staff orientation ("training"). He reminds us of the long-established scaling issue:

"A successful small project does not ensure a successful big project." (p. 111)

It's gratifying to see yet another respected writer endorse the notion of looking at actual work samples as an essential element of recruiting.

None of that, of course, has anything to do with object-orientation. Such principles apply equally to any project, especially one using any unfamiliar tool or technique.

The book includes a dozen short sidebars and articles by other writers, which he calls EWAs ("eyewitness accounts"). They're of varying quality and varying relevance.

and the silly

Mr. Cockburn manages to squander his credibility as an OOP expert with some astonishing claims. For example:

Unfortunately the sound advice and valid insights in this book are outweighed by its serious flaws.

Not recommended


1 -- Undoubtedly at the root of many of the buffer overflow bugs that help to spread virus programs.
2 -- In my OOP courses I often assign one-week homework exercises to design and develop a complete class. Most students manage to finish and a few produce a high-quality result.

Return to book reviews.
Return to table of contents.

Last modified July 14, 2002