[chbot] Agile! Jack Ganssle AUGUST 11, 2014

[Mark Atherton]

sense at last :)

stolen from http://www.embedded.com/ hopefully with full credits included

-mark

============

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 of highlighting those of the 
practices he feels have 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


Jack G. Ganssle is a lecturer and consultant on 
embedded development issues. He conducts seminars 
on embedded systems and helps companies with 
their embedded challenges, and works as an expert 
witness on embedded issues. Contact him at 
jack at ganssle.com. His website is www.ganssle.com.