Search in Book Reviews

The first appendix is about the Team Software Process (which is the key element of this book). It starts by giving you a list of five pre-requisites. The first one may prove to be a stopper for many:

The team members are all skilled and capable of doing the job.

Oh that we should be granted such luxury, more often in my experience it is the task of the team leader to try to find some way to utilize the under-skilled half of his/her team (often the half that is sure that the others are the problem).

In chapter 6 - Changing Engineering Behavior - there is a choice description:

Trying to change the behavior of software engineers is like herding cats. They are very independent people; they all have their own ideas, and they won't tell you what they think, particularly if they disagree with you. They just do what they want to do.

It is only by accepting reality that we have a fighting chance of modifying it. The author has both feet firmly planted on the ground and makes many sensible observations as how management can achieve improved software development. You may think that much that is in this book is obvious, but experience suggests that much management needs to be told the obvious and if they will listen, everyone benefits. If you want change you must provide motivation. If you want to change engineers you must encourage them to make the changes for themselves.

A short book that is well aimed and worth reading. If you want an improved working process either because you are a developer or because you manage developers, reading this book will certainly do no harm. Perhaps being wiling to read and learn is the key, so getting managers to take this seriously will be a major step in the right direction.

Analysis& Design