“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 works 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 advise on communicating business reasons to the team, something that is largely obfuscated in organizations.
However, some chapters are just too short! 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 autmated 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 uneconomic to have all Unit Testing at 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 that is important. 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. I have seen reports of up to 50% of features in software never used and most of these never asked for. Yet again the economics of this area is omitted from the book.
Finally, the authors praise modern software engineering. Any reader of Brooks’ ‘Mythical Man Month’ (an excellent book and one they recommend) will know that issues that plagued the software industry fifty 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 outlined in this book are largely recognized as being somewhat successful. But in my opinion we have a very long way to go.
To summerize, Iwould say, a good book for Project Management teams using Iterative Development techniques but sadly lacking on the Economics of the subject.
Recent Comments