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.
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.
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)
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?
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:
. (p 149)
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:
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.
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.