Book Review: The Economics of Iterative Development

The Economics of Iterative Software Development, by Walker Royce,
Kurt Bittner, and Mike Perrow, covers techniques for achieving more
predictable results with development projects.

Disclaimer: I received a review copy of this book through the PyATL
Book Club.

The goal of the book is to encourage adoption of iterative
development processes
, rather than the old-fashioned waterfall model
(does anyone really still use that model?). In the authors’ view,
iterative processes, where one builds a rough version of a product and
continually refine it over time, yield better results in terms of
predictable schedule and meeting real requirements. This isn’t a new
idea, and they make reference to agile processes such as XP and Scrum,
along with RUP. But the book isn’t necessarily a guide to a specific set
of processes. It’s framed as more of an argument in favor of the entire
class of techniques represented by modern development methodologies.

The authors clearly have experience with development processes and
evaluating and improving performance of teams. Royce is a VP from IBM’s
Rational Services group and a contributor to RUP. Bettner is a CTO at
Ivar Jacobsen Consulting and also contributed to RUP as well as Perrow is a writer within the Rational group at IBM. Their
experience shows in the authoritative tone the book takes when
presenting best practices.

“day-to-day decisions are dominated by value judgements, cost
trade-offs, …”

They start from the premise that software development is less of an
engineering practice and more like a creative endeavor such as producing
a film. Only 1/3 of movies deliver on time and within budget, for
example. The comparison resonates with me since I have always viewed
development work as more creative than mechanical manufacturing or
engineering, although I was never quite sure other types of engineering
were as non-creative as they are portrayed.

The more I think about it though, the more I am inclined to see
managing software development as managing invention, which is even
farther from typical engineering than movie production. With software,
no two products or projects are exactly the same, so the “best
practices” we learn have to be adapted for every situation.

They go on to describe a generalized history of approaches to software
development processes. In the ‘60’s and ‘70’s the attitude was
“craftsmanship”, with lots of customization of tools and processes. In
the ‘80’s and ‘90’s the trend was towards an engineering approach, but
it still had a lot of innovation with new technology and techniques.
Recent techniques have paid more attention to risk, taking advantage of

Write code. Less of it. Mostly high-level languages.

The authors a couple of primary ways to reduce risk in development.
The first is using propose component-based and service-oriented
architectures. By isolating parts of the implementation from one another
and connecting them through established interfaces, you can iterate over
different parts improving as needed. There is also an emphasis on
reducing the amount of “human generated” source code, either through
high-level languages, off-the-shelf components, or code generation
(unsurprisingly, they specifically mention UML-based code generators).

This was about the point in the book where I realized that it was
missing the material needed to back up the assertions and claims being
made. With a name like “The Economics of Iterative Software
Development,” I expected to find more statistics and supporting research
material than is provided. I don’t disagree with any of the authors’
conclusions (indeed, they’re hardly new insights for anyone who has read
a couple of books on agile methodologies). The problem is if I was
trying to use this book to convince someone who did not already accept
the premise, I wouldn’t have any basis for an argument.

This lack of background was particularly evident in chapter 7, where
they talk about ways to “accelerate cultural change” to iterative
development by choosing a high-profile project instead of easing into it
with a pilot project. Their rationale is that the people assigned to
work on high-profile projects are typically the better performers
already, and if you get their buy-in, they will make the change work
because of their dedication. The trick is getting the buy-in in the
first place, of course.

I found the book interesting, well written, and worth reading. It
doesn’t quite stand on its own, though, if you’re looking for ammunition
to change your boss’ mind about process. If you have already decided to
go with an iterative process, it will reinforce your decision and
provide guidance to make it work (particularly in the appendix). But it
didn’t live up to my expectations, based on the title.

Updated: Check out my notes for this book on