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:
Under Pressure and On Time
Author:
Ed Sullivan
ISBN:
0 7356 1184 X
Publisher:
Microsoft Press
Pages:
271pp
Price:
£22-99
Reviewer:
Francis Glassborow
Subject:
writing solid code
Appeared in:
13-4
In my opinion one of the things that Microsoft has done consistently well is publish books about the development process. I am not thinking of books on C++, VB or C# but books about the general process of software development and the management of that. Not everyone agrees with all that they publish but the general level is considerably above average. This book is no exception.

The author brings a wealth of practical experience to the table. For the last seven years he has been a key player in the growth ofNuMegaTechnologies from a company of about a dozen people largely involved with two major franchises (BoundsCheckerandSoftICE) to a company more than ten times the size, marketing internally developed products as well as other franchise software. At the time of writing this book he was Director of Engineering for the company. So much for his credentials.

The book is divided into three main sections. First, and by far the largest part of the book is concerned with 'People, Organization, and Methods'. This starts with the issue of finding the right people and continues through software tools, QA and a brief chapter titledRelease Engineering Fundamentals. In that chapter he deals with issues that are of concern because the product will leave development and become something sold to others. This is an issue that is easily forgotten by some developers who produce something that works fine for them but does not work nearly so well for the customer. Little things like ensuring the product will run on your customer's hardware and not just on the high-end machines you are using for development.

Perhaps one of the more interesting chapters is that on 'Resumes, Interviewing, and Retention.' Those seeking jobs in software development could do well to read this chapter and see what at least one employer admits to looking at. At least as far as this author is concerned the ability to write a good letter of application is an important criterion.

The next section of the book is made up of four chapters under the collective heading of 'Project Definition and Planning.' While whole books can be, and have been, written on such things as requirements, having a compact over-view sustained by practical experience of the ways that things can go wrong is worth reading for all but those who are already experts in the area.

The last part is what most people might have expected to have been the substance of the whole book. Under the heading 'Project Execution' we find four chapters: 'Staying on Course', 'Beta Testing', 'Release Candidates' and 'Project Closure'. Each of these chapters provides valuable insights into the process of delivering a product on time to reasonable quality.

Perhaps the best part of the book is exactly that the author has taken a much broader view of the problem. Without the right people with effective management and quality tools, backed by appropriate requirements, understanding of user needs and concepts of scheduling the satisfactory execution of any product is pure chance and the odds are stacked against it.

The only problem that many readers will have is that the book outlines mechanisms to achieve successful and timely completion, but without high level management commitment to the ideas presented, there is nothing that the ordinary jobbing programmer can do except feel frustrated by the knowledge that there is a better way than that so often experienced in the workplace.