Applying "agile" methodology to non-trivial projects . . .

Mixed Advice on Programming

Jutta Eckstein: Agile Software Development in the Large
2004, Dorset House, ISBN 0-932633-57-9, 234 pages
reviewed by Conrad Weisert, September, 2010, ©Information Disciplines, Inc.

General impression

This little book contains much excellent advice that emphasizes good programming practice. Unfortunately that good advice is more than offset by a torrent of ignorant claims and gratuitous insults to experienced professionals.

The point of the book is to rebut the popular belief that so-called agile methods work well on small projects, but break down on large ones. (Of course, any methodology succeeds if the project is small enough.) If you're considering agile methods for a large project or if you're already struggling with one, you may find parts of this book helpful.

Our vivid imaginations

"Furthermore larger teams, especially in large companies, often believe in upfront requirements engineering because people imagine that accepting requirements later will be more expensive than accepting them earlier. Another reason is that people buy into the possiblity of clairvoyant engineering, which could eliminate the need to change requirements later."—p.19

No, Frau Eckstein, we don't imagine that it costs more to add requirements after code has been written than before. That's a long-established and well-known principle. Indeed the cost of a requirements change in the late stage of a project can easily be 100 times what the same change would have cost earlier.

Nor do we know any "people" who favor clairvoyant processes in software development, and we doubt that Frau Eckstein knows any, either.

Confusion about testing

The author shares the strangely widespread view that unit testing is an agile innovation, resisted by the non-agile community:

". . .we know that tests are our safety nets, but too often, people still do not develop them. Or, even if they do, tests are the first thing to be cancelled when the team finds itself running out of time."—p. 26

"A common and reasonable fear is that testing will slow development down." —p.36

"If the tests are developed after development, as is quite common practice in the industry, they are not much use. This is why a lot of people do not like to test—they don't see the point. —p.36 "The minimum you should insist on is that no code will ever be delivered without a test." —p. 145

While the first three are simply nonsense, at odds with decades of experience and having nothing to do with "agility", the last of those is ambiguous. It could mean either:

  1. no code will be delivered without having been tested. That interpretation is non-controversial and has applied to all code written since the 1950s.

  2. or no code will be delivered without accompanying test driver code. This interpretation depends on to whom you're delivering code and when. It surely applies when we deliver code to the project team for integration into the product, but not necessarily when we deliver a finished product to the customer or to a component library.

Project roles

The index contains entries for various project roles:
RoleNo. of page
systems analyst0
data administrator0
quality assurance9

Some of those references are meatier than others, but we can infer that for Frau Eckstein, like other agilists, systems analysts do not exist. User representatives confer directly with programmers (now called developers) as they did in the 1950s.

Frau Eckstein expresses her disdain for programmers:

"They invent designs that can only be understood by themselves and the computer. They do this because writing code that is too convoluted for their peers to understand is a way of showing off how clever they are."—p. 27

It's hardly surprising then that one of the books she recommends in the bibliography is Alistair Cockburn's Surviving Object-Oriented Projects, notorious for insulting programmers.

Interesting sidebars

Scattered through the text are articles, called "expert boxes" by other contributors. They're of varying quality and varying interest. The piece on Open Source (pp 78-82), by Dierk König is especially interesting.

A German version is available.

Recommended as a curiosity for discerning readers.

Return to book reviews.
Return to table of contents.