Search in Book Reviews

Let me start by getting the largest single irritant in this book off by chest. Throughout the Forward and Preface the author continues to refer to two books, the one being reviewed here and another volume titledMore Process Patterns. It is infuriating to be told that everyone should read chapter 10 of a book they have not got, and which does not even appear on the list of series titles at the front of the book. I hope that the publishers have release of this second book marked as 'most urgent.' The author describes a process pattern to be a collection of general techniques, actions, and/or tasks (activities) for developing object- oriented software. The biggest quarrel I have with that is the end of the sentence. I can see no reason for claiming some special constraint that they apply only to object-orientation, and in general I do not see why they are something specially related to software. Certainly this book applies the process pattern concept to software and the author claims that he is focusing specifically on object-oriented software.

There is a considerable input from the Capability Maturity Model into the general principles provided by this book. Like the CMM the author is at pains to point out that he is not trading in quick fixes or silver bullets - good, I am getting tired of those that make unattainable promises that seduce management into blaming employees for not being miracle workers.

I think the author is stretching things a little by using the word pattern. Certainly the book distils the wisdom of experience but it does not result in a pattern catalogue as we might expect from other forms of software pattern. What we do have is a codification of good development processes coupled with a warning that you must work at them. Blindly using a codified process is probably worse than nothing as it will add a layer of paper- pushing to already over-burdened employees. The frequent check-lists found in this book must be followed in spirit. It is no good just checking the item 'Access to key users, technical experts, and financial experts has been obtained.' You must understand why that is important and what is achieved by contact. It is not much use having access to technical experts if you do not consult them or ignore what they have to say when you do.

Like much that is written in this area, solitary study will get you nowhere. First read the book, then tactfully persuade others to do so, including members of the management. If you cannot get support from the latter, go and do something else because you will be wasting your time otherwise.

When you have read this book (which if you either are, to intend to be, involved in large scale software development you should do.) then wait for the right moment to offer it to those with the ability to make changes. In the meantime you can make use of some of the tips that the author has scattered through this book. For example, you may be a simple programmer but the tip (on page 154) 'Invest the time to learn the basics of finance' is well worth taking. I have lost count of the number of times I have heard of an employee loosing an argument about resources, methodology etc. simply because they had too little understanding of finance. Show management that you understand the bottom line and convince them that your proposal will have a positive impact and you are almost home. Indeed belief that you have considered finance will gain you a lot of ground.

If you work in the software industry you should take time to read this book, thoughtfully.