ACCU Home page ACCU Conference Page
Search Contact us ACCU at Flickr ACCU at GitHib ACCU at Google+ ACCU at Facebook ACCU at Linked-in ACCU at Twitter Skip Navigation

Search in Book Reviews

The ACCU passes on review copies of computer books to its members for them to review. The result is a large, high quality collection of book reviews by programmers, for programmers. Currently there are 1918 reviews in the database and more every month.
Search is a simple string search in either book title or book author. The full text search is a search of the text of the review.
    View all alphabetically
Title:
Winning with Software
Author:
Watts Humphrey
ISBN:
0 201 77639 1
Publisher:
Addison-Wesley
Pages:
229pp
Price:
£26-99
Reviewer:
Francis Glassborow
Subject:
business
Appeared in:
14-2
Look again at that page count because it is deceptive, the appendices start on page 115. Then note that the subtitle addsAn Executive Summary. Yes this book is primarily aimed at management So let me hit a few high spots so you will know if you want to encourage your management to read it (you might spend an hour or so reading it in your local bookshop first)

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