Reading this table of contents actual depressed me in some ways. I must have read a half dozen books that cover the contents and they all ring true, but the frustrating part is the effort it takes to work on any issue when the majority of your company doesn’t share the same view.
To me this table of contents is a great bullet point list that non-software engineers should read. I personally work in the games industry and I think that many of the other disciplines (art, design and management) really don’t understand anything about building software. Some of them have been doing it for years but I don’t think they realize the truth of the statements in the list.
It kind of reminds me of a comment one of my friends made at work about STL code. We both love it but we realize that you have to code to the lowest common denominator of education to have a reusable and maintainable code base. Maybe our game studio is a bit in the dark ages in not pushing people to learn these new skills, but I find this table of contents a similar kind of problem where if other people in my company do not get creating software (an example would be only budgeting 20% of the software cycle for bug fixing and no maintenance budget at all) it just makes me want to stop reading and start fixing things with what I know already.
To end this long rant, perhaps this is something I would add to the list:
“Many engineers know more about software management than their managers, few of them want anyone to find out they do lest they will have to manage”