A balanced but shallow view . . .

A Comparative View of
"Agile" versus "Plan-driven" Methodology

Barry Boehm & Richard Turner Balancing Agility and Discipline
2004, Addison-Wesley, ISBN 0-321-18612-5, 260 pages
reviewed by Conrad Weisert, October, 2003, ©Information Disciplines, Inc.

General impression

Any book about "agile" methods that doesn't sneeringly condemn more disciplined approaches is novel and welcome. Boehm and Turner have tackled a controversial and often polarizing topic.

The authors have succeeded in shedding much needed light on this contentious issue and in moderating the tone of the debate. Experienced programmers, project leaders, and development managers will find useful clarification, guidance, and advice here. The book is marred, however, by some surprisingly naive oversimplifications and less than fair and balanced comparisons.

Unfortunate terminology

Many readers know that I and others have complained about appropriating the word agile to describe extreme programming and similar approaches. We've given up on that one in the face of overwhelming volume of articles, books, and courses. Boehm and Turner go even farther, calling practitioners of those methods agilists.

Even more troubling is the choice of plan-driven to describe any more disciplined approach. That term reeks of burdensome bureaucracy, and indeed many of the authors' examples of the disciplined side exhibit the most painfully rigid and bureaucratic structure. Presumably they avoided the term disciplined given in the title, because the agilists claim that their approach is indeed a disciplined one. Alternatives without such negative connotation include planned and structured.

Every methodology breakthough over the past 40 years has been compared with the "traditional approach". Today's innovation becomes next year's tradition. That term is so overworked and meaningless that it ought to be put to rest. It should especially be avoided as a description of what only a small minority ever practiced, as in:

"Traditional approaches are best exemplified by the Capability Maturity Model for Software (SW-CMM), which gained prominence in the late 1980s and early 1990s." -- (p 2)

Analysis and Design confusion

Throughout the book the author1 fails to distinguish between the roles of systems analyst and programmer. Of course, some of the agile methods do away altogether with systems analysts, but a fair and balanced comparison ought to have given proper recognition on the disciplined side to the process of capturing and documenting users' requirements, i.e. a system specification. If the allegedly disciplined approach skips the most important life-cycle phase, then how much can we learn from the comparison?

For example:

Knocking down straw men

A common but somewhat disreputable debating technique is to attribute to your opponent an extreme position that he doesn't hold and then to demolish that position with unassailable logic. The arguments on both sides of the agile versus disiplined debate are surely strong enough without resorting to such techniques. Here are two examples that irritated me:

  1. If a . . lead bullet can slay a software wolf this year then it will be able to slay the wolf's offspring next year. Examples of techniques where this fallacy is apparent include:
    • The sequential requirements-first waterfall process model that could work quite well for 1960s or 1970s batch, sequential, noninteractive applications.
    • .
      . (p 149)

  2. Unfortunately, software engineering is still struggling with a "separation of concerns" legacy that contends translating requirements into code is so hard that it must be accomplished in isolation from people concerns. A few quotes will illustrate the situation:
    • The notion of "user"cannot be precisely defined, and therefore it has no place in computer science or software engineering. [Edsger Dijkstra, from the transcript of a 1979 panel discussion]
    • .
      . (p.153)

Now I take issue with above not because I disagree with the authors' points (although I do) nor because they trotted out the tired waterfall canard, but rather because those arguments are invalid or contrary to fact. Specifically:

Simple or simplistic?

Everyone favors simplicity in design, but we don't always agree on what's simple. "Simple" is not a synonym for:

Indeed a truly simple design is often the product of a long creative process and careful review. (Recall that the costly and wholly unnecessary Y2K crisis was the result of a misguided view of what's simple.)


I suppose it's acceptable for a professional book to plug a commercial product, but only if that product provides some unique capabilities germane to the principles being put forth. Boehm and Turner's dozen plus references to one C.A.S.E. tool vendor's proprietary life-cycle, however, are unnecessary and undermine the readers confidence in their objectivity. Other Addison-Wesley authors, including the vendor-originator, manage to refer to "The Unified Software Development Process" by its proper generic name.

Reference value

A valuable feature of the book is the set of appendices that summarize popular variations on the two approaches and related techniques.

Recommended for the discerning and critical reader

1 -- Multiple-author books often exhibit internal inconsistencies. From the flavor of the discussions and conflicting earlier material (p. 38), I'm guessing that this confusion originated with just one of the two authors.

Return to book reviews.
Return to table of contents.