Murray Cantor writes with an eloquence and brevity that many would do well to take note of.
Murray Cantor writes with an eloquence and brevity that many would do well to take note of. There is no needless repetition of largely irrelevant points here and this book should be recommended simply because it is a pleasure to read, but we should consider the material it presents first.
The book addresses two major issues; the nature and frequent failure of software development and maximising the chances of successful software development.
The first of these issues is handled in a simple and comprehensible way. Difficult conceptual issues are explained in an approachable fashion, allowing the least technical of people to understand the issues involved. For example, the author elegantly explains why the heavily controlled processes of the past have failed; trying to force a linear model onto a non-linear process is doomed to fail.
The presentation of alternatives to traditional software management is not quite as good. The general concepts are well handled, but there is a little too much pressure towards the Rational Unified Process. Perhaps understandable given the author's role at Rational, but nonetheless, the book gives the impression that the RUP is the only reasonable approach to use, which I felt was perhaps unfair. Specialists might see through this commercial pushing, but managers without a significant IT background - who really should be amongst the audience for this book - may not pick up on this and might see the RUP as the next silver bullet. That is not to say that the RUP is not a good solution, but people shouldn't be guided into thinking it is the only solution.
I have chosen a quote to give as an example of how Cantor shows a deep understanding of not just software development processes, but software development people as well.
The fact that programmers can control the unforgiving machine makes them different and creates a sense of separation from those who cannot. [...]. If you cannot write a program, you simply do not get it. If you do not get it, how can you possibly control what the programmers do?
This book is well recommended to everyone from developer to tester to manager. But for the periodic pushes towards the RUP, a highly recommended rating might be justified, but that aspect just dragged it down slightly for me.