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 jazz.net. 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 automation.
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 readernaut.com.