Customer Reviews

The Economics of Iterative Software Development: Steering Toward Better Business Results

5 star:		(3)
4 star:		(2)
3 star:		(0)
2 star:		(1)
1 star:		(0)

 

 

This is a lean book (small size, only 170 pages) which attempts to help managers and decision makers move to iterative approaches over waterfall. The book's well written and has some good, thought-provoking discussion in it.

You won't find discussions of specific methodologies in this book, but you will find repeated emphasis on critical concepts like delivering running systems over useless documentation (not ignoring documentation, mind you, but delivering the right amount of it). Doing the right amount of planning at the project's start is also emphasized: avoiding over-architecting and big design up front.

It struck me that much of the authors' definition of "iterative" development is subtly scattered around the book. It's not always In Your Face, and that's actually OK because you're able to better focus on their deeper points.

The economics part of the book's title comes through some good discussion on ensuring you're delivering business value, plus an entire section on measuring your project's success. There's good discussion in those sections to help you understand opportunity cost (if I do this, what else am I unable to do?), net present value, and a great example on prioritizing features based on their value to the business.

Some things in the book are a little vague for my tastes, but the authors did a nice job of keeping the book brief, concise, and on target.

Overall it's a very good, useful read.

The title of "The Economics of Iterative Software Development - Steering Toward Better Business Results" jumped out at me since I'm a software developer at a bank. Software and economics in the same title - cool!

The book is what I call good airplane reading. It's interesting to read, easy to read without a whole pile of focus, can be read in a few hours and doesn't physically weigh to much. The book is mainly geared towards software development managers. Particularly those who want to being iterative development or make their projects more iterative.

The economics comes in through the model of COCOMO, a number of graphs and formulas like net present value. It's not the kind of economics that you have to be an economist to understand. Or even like math for that matter.

In addition to the economics, the book covers things like factors for resistance to change. I particularly liked the section on measurements and how people adjust their over/under reported based on how they think the measurement will be used. I also like the appendix listing the top ten books for managers (like Peopleware) and why to read each one.

Overall, I enjoyed reading the book. I think it is a good book to either show your manager or to read to get a feel for the criteria important to management when selling an idea. And without having to read a whole project management book at that.

Congratulations Walker for clearly communicating what your father Winston tried to tell the software world 40 years ago. The waterfall was a "virus" wrongfully extracted from Winston Royce's famous 1970 paper "Managing the Development of Large Software Systems". You should have dedicated the book to him!

While some minor points in this book may be misleading for the agile novice, it contains sound advice and core reasons why companies need to improve by implementing agile processes. The basic premise is sound and the key factors of reducing complexity, getting the right people, improving the process, and creating a great development environment will help companies ready to make that commitment have a much better chance of beating the odds.

Thank You!

Walker Royce, Kurt Bittner and Mike Perrow's ECONOMICS OF INTERATIVE SOFTWARE DEVELOPMENT: STEERING TOWARD BETTER BUSINESS RESULTS provides software development libraries with a strong software management guide discussing how business and technical managers can blend economics and integrative development to receive the best from limited budgets. From improvement in development to using automated tools to improve effectiveness, both business and software collections will welcome this.

This book was shipped to me quickly. It is to be used as part of the readings for a Software Engineering course this fall. While the text is directed towards the economics of software development, it provides a lot of background for college students.

"The Economics of Iterative Software Development" gave me some excitement, thinking there was finally a concise reference from experts giving examples of projects they participated on, why they failed (with a breakdown of specific areas) and how the different aspects of developing iteratively resolved these issues in future projects. - Unfortunately I was slightly disappointed.

The first chapter is interesting and uses statistics from reputable sources such as the Standish Report. However, the remainder of the book is more of a Project Management guide for both experienced and junior project managers (and project owners) to determine why Iterative Development will work in the software industry.

The authors clearly have experience and this shows. The Appendix `Getting Started With Iterative Project Management' is good and steps through the requirements of setting this process up. I especially like how the authors give advice on communicating business reasons to the team, something that is largely obfuscated in organizations.

However, some chapters are just too small! Four pages on Automation! This is one of the largest economic gains in the development lifecycle. I would have liked to have seen concrete examples of which parts of the development lifecycle they automated and how much time or money was saved.

There are some points in this book I would question mainly:
-"Test coverage should be 100% of all scenarios." If this refers to all testing then it is actually uneconomical to get Unit Testing to 100%.
-Most of the cost of software is in post-release maintenance, yet nothing is discussed about this. The authors state "Achieving results is more important than performing activities as part of a process". - I'm sure this has always been the case but it is WHAT processes we need to concentrate on. For example; if I create a deliverable on time but it is not maintainable, is this acceptable?
- One huge economic drain is the YAGNI (You Ain't Gonna Need It) principle where I have seen reports of up to 50% of features in software never used and most never asked for. Yet again, there is nothing on the economies of this.

Finally, the authors praise modern software engineering. Any reader of Brooks' Mythical Man Month (an excellent book and one they recommend) will know that the issues that plagued the software industry 45 years ago are still largely apparent.
Iterative development is not a modern way of thinking as projects have used it over the last 30 years. However the techniques used in implementing this strategy have been lacking. The techniques in the book are largely recognized as being somewhat successful. But in my opinion we have a very long way to go.

To summarize, I would say, a good book for Project Managing teams using Iterative Development techniques but sadly lacking on the Economies of the subject.