Bertrand Meyer is one of the most literate authors in computer science. His latest work, Agile!, is an example. It's a 170 page summary and critique of the leading agile methods. The introduction gives his theme: "The first presentations of structured programming, object technology, and design patterns. were enthusiastically promoting new ideas, but did not ignore the rules of rational discourse. With agile methods you are asked to kneel down and start praying." The book burns with contempt for the eXtreme attitudes of many of agile's leading proponents. He asks us to spurn the "proof by anecdote" so many agile books use as a substitute for even a degraded form of the scientific method.

This is a delightful, fun, witty and sometimes snarky book. The cover's image is a metaphor for the word "agile": a graceful ballet dancer leaping through the air. He contrasts that with the agile manifesto poster: "The sight of a half-dozen middle-aged, jeans-clad, potbellied gentlemen turning their generous behinds toward us."!

He quotes Kent Beck's statement "Software development is full of the waste of overproduction, [such as] requirements documents that rapidly go obsolete." Meyer could have, and should have, made a similar statement about software going obsolete, and that both software and requirements suffer from entropy, so require a constant infusion of maintenance effort. But he writes "The resulting charge against requirements, however, is largely hitting at a strawman. No serious software engineering text advocates freezing requirements at the beginning. The requirements document is just one of the artifacts of software development, along with code modules and regression tests (for many agilists, the only artifacts worthy of consideration) but also documentation, architecture descriptions, development plans, test plans, and schedules. In other words, requirements are software. Like other components of the software, requirements should be treated as an asset; and like all of them, they can change". (Emphasis in original).

He describes the top seven rhetorical traps used by many agile proponents. One is unverified claims. But then he falls into his own trap by saying "refactored junk is still junk."

The book's subtitle is "The good, the hype, and the ugly," and he uses this to parse many agile beliefs. Meyer goes further and adds the "new," with plenty of paragraphs describing why many of these beliefs are actually very old aspects of software engineering. I don't see why that matters. If agile authors coopt old ideas they are merely standing on the shoulders of giants, which is how progress is always made (note that last clause is an unverified claim!).

The book is not a smackdown of agile methods. It's a pretty-carefully reasoned critique of the individual and collective practices. He does an excellent job highlighting those of the practices he feels has advanced the state of the art of software engineering, while in a generally fair way showing that some of the other ideas are examples of the emperor having no clothes. For instance, he heaps praise on daily stand up meetings (which Meyer admits are not always practical, say in a distributed team), Scrum's instance on closing the window on changes during a sprint, one month sprints, and measuring a project's velocity. (I, too, like the agile way of measuring progress but hate the word "velocity" in this context. Words have meaning. Velocity is a vector of speed and direction, and in agile "velocity" is used, incorrectly, to mean speed).

One chapter is a summary of each of the most common agile methods, but the space devoted to each is so minimal that those not familiar with each approach will learn little.

Agile! concludes with a chapter listing practices that are "bad and ugly," like the deprecation of up-front tasks (e.g., careful requirements gathering), "the hyped," like pair programming ("hyped beyond reason"), "the good," and "the brilliant." Examples of the latter include short iterations, continuous integration and the focus on test.

The book is sure to infuriate some. Too many people treat agile methods as religion, and any debate is treated as heresy. Many approaches to software engineering have been tried over the last 60 years and many discarded. Most, though, contributed some enduring ideas that have advanced our body of knowledge. I suspect that a decade or two hence the best parts of agile will be subsumed into how we develop code, with new as-yet-unimagined concepts grafted on.

I agree with most of what Meyer writes. Many of the practices are brilliant. Some are daft, at least in the context of writing embedded firmware. In other domains like web design perhaps XP is the Only Approach To Use. Unless TDD is the One True Answer. Or Scrum. Or FDD. Or Crystal.

Published August 6, 2014