Bertrand Meyer.
Agile!: the good, the hype and the ugly.
Springer. 2014
I’ve been a fan of aspects of Agile Programming ever since
I
first read about it.
In particular the incremental style works very well in
building software to support scientific research,
where you really don’t know what you need to do next
until you have run the prior experiments and come up with the next hypotheses;
the discipline of
YAGNI
(“You ain’t gonna need it”) can save a lot of time and effort here.
The “always have a working system” (continuous integration) part also works well for student projects,
with their rigidly time-boxed hand-in dates.
However, I also have a background in formal methods,
so some of the more seemingly heretical and potentially “hacky”
bits of the process do raise an eyebrow.
That’s where
Agile! comes in.
Bertrand Meyer is in the “strong software engineering” camp,
strong on specification and design,
and the inventor of “
design by contract”
in the 1980s, an approach of which I’m also a fan.
What is
he going to say about this new approach?
Unsurprisingly, he thinks some of it is bad; very bad.
More surprisingly, possibly, he thinks some of it is not just good, but even “brilliant” (his term).
He goes through the various components of the various Agile approaches, describing and critiquing them.
He puts most emphasis on Scrum, with which he is most familiar
(even being a certified Scrum Master), but also covers Crystal, XP, and Lean.
In summary, the ugly includes the lack of upfront specification and design
(even allowing for the fact it will change later)
and specifically user stories as the basis for requirements
and test-driven development as the basis for design;
the hype includes pair programming and collective code ownership; the good includes refactoring;
the brilliant includes iterative development, continuous integration,
and test first development (associating a test with every piece of functionality).
His argument for up-front specification and design includes the need for finding good
abstractions,
which will
not automatically emerge from a test-code-refactor cycle.
A specification is more abstract than a test suite, because it covers all the cases
(thereby removing the problem of induction, or inducing the general from the specific).
Similarly, he argues that user stories are to requirements what test cases are to specifications,
including the same problems of lack of generality and completeness.
We presumably need another aphorism to complement Dijsktra’s famous observation that
testing can show the presence of bugs, but never their absence.
Maybe it should be something like
user stories can show the inclusion of functionality, but never its omission.
My only peeve about the book is some of the typography.
Occasional paragraphs that are “asides” are set in a smaller font size.
Every time, I initially parsed these as quotations, and had to backtrack.
Notwithstanding this minor point,
Agile! is an excellent thoughtful critique of Agile methods.
Although Meyer introduces and describes all the concepts he critiques,
I don’t think it is a stand-alone text, as those descriptions are somewhat brief.
However, is should be required reading for anyone using, or about to use,
an Agile approach.
At 170pp, it is a fast, if dense, read.
I laughed out loud on several occasions.
For example, he comments on
the picture accompanying the agile manifeso:
p1.
The sight of a half-dozen middle-aged, jeans-clad, potbellied gentlemen
turning their generous behinds to us appears to have provided the decisive sex appeal.
Personally, had I wanted to convey the suggestion of agility,
I might have turned to something like the cover photograph of this book —
which only demonstrates how out of tune I am with the times,
since the above picture was successful beyond anyone’s dreams.
For all my book reviews, see
my main website.
