There is a lot of software development truth in this book. At least, a lot of what the author experiences as being true. And in one area, he makes it abundantly evident that software development is probabilistic rather than deterministic.
The conventional "design it then constructs it, and you can have many mediocre minds working in parallel as long as highly clever individuals do the design for them first" model would be effective if it were deterministic. It also doesn't. It falls short time and time again.
It also discusses the warning signals of failure, and the kinds of factors that indicate that your project will probably fail if you don't have them. For instance, having a thorough understanding of who is engaged in what: I can assure you that whenever I have let go of a project's specifics, problems have begun to creep in. I'm not sorry for wanting to know exactly who, what, where, when, and why at this point. Being instructed on how to perform your job differs significantly from being asked to thoroughly describe your work.
