Computing Reviews
Today's Issue Hot Topics Search Browse Recommended My Account Log In
Review Help
Agile! : The good, the hype and the ugly
Meyer B., Springer Publishing Company, Incorporated, New York, NY, 2014. 170 pp. Type: Book (978-3-319051-54-3)
Date Reviewed: Sep 18 2014

The purpose of this excellent book is to “enable readers to benefit from the good ideas in agile methods and stay away from the bad ones.” The author provides both a description and a deep and justified assessment of key agile ideas and approaches. The description is complete and concise, without partisanship (“with agile methods you are asked to kneel down and start praying”), intimidation (“the very name of the approach, ‘agile’, a brilliant marketing decision ... is enough to make any would-be skeptic think twice”), and extremism. The description is clearly separated from the assessment and is not tied to a particular method, not drowned under anecdotes, and “not interspersed with a constant exhortation to join the cult.” The overall presentation is elegant, clear, and understandable, without hype, sermons, or slang. It can be used both by novices and by experts (and critics).

Regretfully, in software development, interactivity led to instant gratification [1], and “the writing of complicated code and the nasty decryption by others is apparently considered easier or more economical than the careful design and description of clean interfaces of modules” [1]. As E. W. Dijkstra emphasized, coding “should ... be postponed until you are as sure as sure can be that the program you are about to code is, indeed, the program you are aiming for” [2]. Nevertheless, the “why isn’t Sam coding anything?” (WISCA) mentality is often still with us. In agile approaches, coding is not postponed.

The very nice second chapter, “Deconstructing Agile Texts,” discusses techniques “of questionable soundness” and “outrageously rhetorical devices,” a triumph of marketing, used by agile authors to advocate their approaches. Chapter 3, “The Enemy: Big Upfront Anything,” presents a calm and reasonable discussion of the principal ideas of plan-based approaches. Meyer agrees with the agile criticism of huge requirements documents running into thousands of pages; with the notable exception of life-critical systems, such documents are almost always useless. However, appropriate abstraction takes care of requirements documents, especially taking into account that detailed requirements may not and often need not be available up front. Meyer properly stresses that “there is no justification for renouncing the basic engineering technique of specifying what you are going to do, in writing, and at appropriate level of detail, before you do it.” In other words, “make sure that we think before we shoot.” (Specifications exist anyway in the heads of the stakeholders and developers, but more often than not these tacit specifications differ from each other.) Furthermore, Meyer observes that elementary professional competence requires recognition of the difference between problem and solution: for any business, its business domain model, independent of any computer-based implementation, exists and should be made explicit. In doing so, tacit assumptions should be articulated (this is not always articulated by Meyer). Different abstraction levels and viewpoints should be used for producing and understanding information technology artifacts to distinguish between requirements (of different stakeholders), design (that ought to be orders of magnitude simpler than code), and implementation. All this has been well known since the 1960s, although too often ignored. Meyer refers to (other) Dijkstra’s and Wirth’s papers and to the famous Proceedings of the NATO Software Engineering Conference [3], but regretfully does not mention a then-famous 1970s college textbook [4] that includes many excellent organizational and technical ideas, some of which are now marketed as agile ones, often under different names. My experience suggests that quite a few (relatively) recent graduates have never heard about any of the above authors.

The following chapters of the book present and assess agile principles, agile roles, agile practices (managerial and technical), agile artifacts, agile methods, and dealing with agile teams. Meyer observes that principles must be abstract (as opposed to practices), falsifiable (as opposed to platitudes), and prescriptive; therefore, he replaces the “official agile principles,” some of which are not principles, with a usable list. While quite a few principles include important and useful contributions, the insistence on minimal software and the “agile, let’s-just-do-what-we-need-now” general approaches are “some of the most absurd and damaging contributions of agile methods” that may lead to “catastrophes [similar to those] that caused billions of dollars of wasteful efforts, [like] the MS-DOS 640K memory limit, the Y2K mess, [and] the initial size of IP addresses.” While scenarios (“use cases” or “user stories”) are very valuable as specific examples, replacement of specifications with scenarios is, as Meyer observes, “one of the most widely practiced and most damaging agile concepts.” This is because in too many situations user stories work (the managers get their demos), but the project fails: first, due to the focus of delivering visible functionality, the hard problems including infrastructure are repeatedly put aside, and second, due to feature interactions, feature-based development, a core idea of agile methods, “exists only in the land of make-believe.” Meyer stresses that “to focus on the visible at the expense of the essential is irresponsible,” and the agile reliance on scenarios often misses the essential that can be found only in the business domain model or requirements. Somewhat similarly, in discussing an important (but not new) agile contribution of the encouragement to involve customers, Meyer notes that there is no such thing as “the customer” and that rejection of trying to collect viewpoints of all stakeholder categories “appears pretty irresponsible.”

The emphasis on simplicity advocated by agile approaches is also not new: it has been long stressed by Dijkstra, Wirth, Hoare, and other proponents of rigorous elegant programming based on a small system of clear concepts resulting in a well-defined system structure, but this appears to be “not a concern of agile methods.” On a more positive note, one can wholeheartedly agree with the agile emphasis on testing (“no code without test”), on regression testing (“do not move on until all tests pass”), and on freezing of requirements during a sprint. At the same time, Meyer properly observes that “you can stop listening to the [agile] advice when it becomes dogmatic” and uses the “brilliant idea of the daily meeting” and daily build as examples. The concept of a self-organizing team is another very good idea that ought to be used carefully: Meyer uses the I Musici ensemble, one of the best chamber orchestras in the world, as an excellent example of a mature team, at the same time stressing that not all teams are talented enough. As to the nice and useful agile idea of refactoring, one can only agree with Meyer when he stresses that a truly big (complex) refactoring is typically not a sum of small refactorings because additive complexity is not the same as multiplicative complexity.

I disagree with Meyer’s assessment of pair programming as useful but hyped beyond reason. It is certainly not new: egoless programming, while close to but not exactly the same as pair programming, has been described in [4] and used since the 1960s, and is different from coding standards. In pair programming, program design considerations and design processes are made explicit by explaining them to a colleague, while in a post-factum code review they might be at least partially forgotten (note that [4] starts with program reading, and that Knuth’s literate programming [5], the main task of which is “explaining to human beings what we want a computer to do,” makes design considerations explicit in writing). At the same time, one can only agree with Meyer that pair programming, as any other single work pattern, should not be forced upon everyone, especially upon “solitary excellent programmers.”

The last chapter, “The Ugly, the Hype, and the Good: An Assessment of the Agile Approach,” as promised, provides a very readable assessment. The excellent Index includes almost anything of interest, with only a few exceptions: the term “marketing” is missing, as well as the more technical term “abstraction,” although these concepts are discussed throughout.

More reviews about this item: Amazon, Goodreads, Dr. Dobbs

Reviewer:  H. I. Kilov Review #: CR142727 (1412-1006)
1) Wirth, N. A brief history of software engineering. IEEE Annals of the History of Computing 12 (2008), 32 – 39.
2) Dijkstra, E. W. Why is software so expensive?. In Selected writings on computing: a personal perspective. Springer-Verlag, New York, NY, 1982, 338–348.
3) Naur, P.; Randell, B. (Eds.) Software engineering: report on a conference sponsored by the NATO Science Committee. In NATO Software Engineering Conf. (Garmisch, Germany, Oct. 7-11, 1968) NATO, Brussels, Belgium, 1969.
4) Weinberg, G. The psychology of computer programming. John Wiley & Sons, Inc, New York, NY, 1971.
5) Knuth, D. E. Literate programming. The Computer Journal 27, 2 (1984), 97 – 111.
Bookmark and Share
  Reviewer Selected
Featured Reviewer
General (D.2.0 )
Would you recommend this review?
Other reviews under "General": Date
Development of distributed software
Shatz S. (ed), Macmillan Publishing Co., Inc., Indianapolis, IN, 1993. Type: Book (9780024096111)
Aug 1 1994
Fundamentals of software engineering
Ghezzi C., Jazayeri M., Mandrioli D., Prentice-Hall, Inc., Upper Saddle River, NJ, 1991. Type: Book (013820432)
Jul 1 1992
Software engineering
Sodhi J., TAB Books, Blue Ridge Summit, PA, 1991. Type: Book (9780830633425)
Feb 1 1992

E-Mail This Printer-Friendly
Send Your Comments
Contact Us
Reproduction in whole or in part without permission is prohibited.   Copyright 1999-2024 ThinkLoud®
Terms of Use
| Privacy Policy