Configuration Management Principles and Practice (Agile ... (ISBN 0321117662)

A good insight into Configuration Management:
This volume should be prescribed reading for all IT professionals. Everybody but everybody has an opinion on the merits or otherwise of Configuration Management, but a better understanding would help us all. People not actively part of Configuration Management (CM) will then say, "Yes, it is both more important and more involved that I had thought hitherto". There are five parts to the book; what is CM, the data required for CM, roles within CM, CM in practice and improving CM. The last three are probably the more interesting, but without the first two, it is talking into a vacuum. Throughout, there is emphasis that CM is a tool to be used, and should not become a priority in its own right. Good CM should provide benefits; unfortunately, those who receive the benefits are not always those who have paid the cost (in terms of extra effort and/or information that is required of them). In the first two sections, there is a lot of material that seems repetitive. An example of this is material regarding the naming of configuration items, deliveries, etc. However, this is also an advantage, as chapters or parts of chapters can be read in isolation. I particularly like the use of the same examples in various parts of the text. When referred to, there is usually a diagram, and this is in text, rather than referring to another page in another chapter. Table 15-1 is the same as table 6-1. In books where the diagram is NOT repeated, but the reader referred back to re-read the other section, they never do! Fundamental questions about what to include under the control of CM are addressed (although not always prescriptively answered). What should be included in the CM system? Do you include program source and object code, just source code, or source and the compiler? If the compiler is not included, it may not be possible to amend code for old platforms. Similarly, all tools should be potentially under CM control. Otherwise, a document written is an obscure word processor format may be available in the future, but not the means to even read it easily? There is discussion about the need to capture both physical objects (PC's, memory boards) AND electronic objects. In this case, CM can partly overlap with asset management; it is other ways very different from the latter. However, the author stresses the need to know the boundaries of CM; the defining of a software delivery is not the responsibility of the CM team. Similarly, the use of variants is a design decision, not decided or dictated by those in CM. The latter is essentially an administrative task, concentrating on the four cornerstones; identification, storage, change control and status reporting. The challenges of these four categories are brought out in the latter parts. Most people would agree that documents need to come under CM control at some point. The storage of documents can present challenges, particularly if a master document has many composite parts. There are also needs to take account of cross-references (which may be different to the formal linkages that are reported by the CM tool). Much information can be gathered from the information available through CM. A well-made point is that there is no point in gathering information if no one is going to use it. Anne Mette's first language is not English, and sometimes this shows. It is difficult to define how this is the case, but sometimes the use of language can be an advantage. Some things are described as being `an inspiration', not an expression that many would necessarily have chosen. That comes across well. However, do not confuse the style with the substance. The latter is the most important, and it is a very good standard. How do fill a book of 350 pages on CM? Several items are covered that are not exactly mainstream CM, but are very relevant and appropriate to the discussion. The section on `people roles' comes over well, and is part of the selling of CM as a discipline. This section draws on the work of Dr Meredith Belbin, and his nine team roles, applying this specifically to CM. The last comments are reserved for the final part, allowing the CM process to be part of the overall Process Improvement drive within an organisation. If there is no CM process in place (not to be confused with there being no CM tool in place), it can be difficult to know where to start. An apt comparison is about a centipede thinking about how to walk - too much thought makes for a tangled heap in a ditch, instead of just doing it. The author says go for quick cheap wins, and if possible base any initial procedures on existing practices. This will significantly enhance the chances of success. CM is a big topic. This volume brings out many of the issues that are involved, and gives guidelines on overcoming some specific challenges. There are practical examples, but these are more in the line of serving suggestions, rather than a fixed menu. Peter Morgan, Bath, UK (morganp@supanet.com)

Very disappointing - just theory, not agile:
This book is the most disappointing book I read for years. The book is published as part of the "Agile Software Development Series". If you know agile software processes you know they are very hands on. They are for team up to 10 maybe 20 people. Agile processes focus on delivering working software, not on documentation and too much formalism. The focus of this book is the complete oposite. For me, it targets projects with at least 50 or more team members in very large organisations. Far away from agile. The second thing I don't like is that it's all just theory in this book. But no practice how I really implement configuration management in my company. Which tools do I need for what (ok, there is one page about that) and so on. All in all, very disappointing and definitly far away from agile processes.

Sound background and concepts for CM:
If you are going to be working in the field of build and release management, then you will need a good background and working knowledge of Software Configuration Management. This book is the one that I believe will most readily enable you to achieve this. It doesn't look at specific techniques or tools, just what SCM is and why we need to do it.

Room for improvement:
First, I must agree with other reviewer that it is odd that this book is in "The Agile Software development series". It reads more like an "old-school" book, that may well be used at university for an "encompassing" "fool-proof" view into CM. I bought this book on reading the other reviews and since it was an "agile" book (almost all other agile books I have read are concise and worthwhile, packed with useful thoughts). This was, from that perspective, a great dissapointment. My recommendation: Read the table of contents of this book. It is quite telling. In short: 1 chapter definition, 2 on standards/maturity models, 4 on what fields go into a CM system (phew), 5 on roles in CM (yup, you read that right). Then we get to the "practice" (part 4): 3 chapters that again list suggestions for id's of items, storing them, tracing them, etc. Heads up, here is the agile chapter (18). Or rather, its a section. Then there are some chapters that seem interesting but fail to be. Lastly we get 5 more chapters on maturity models, this time on how to achieve them. My biggest issues with the book are the constant repetition and the lack of form. Every chapter is a listing of things, the train of thought seems to be derived from a powerpoint slidedeck. I am impressed that the author managed to actually write a book that is as boring as this, constantly listing and reiterating points already touched upon. I would have wanted the maturity model coverage in a separate book and any knowledge left after that condensed in a useful format. I am sorry to say that I cannot find this book that useful today. Were I charged with implementing a very formal SCM project at a fairly large shop, then... I would have looked into it seeing as it sits in the shelf, but I probably wouldnt use it then either. Sorry.

A Useful Survey Of Present-Day CM But Needs Supplementation:
In what hopefully will not be an over-repetition of other's comments, I found this book generically descriptive, theoretical, and quite dense. One of the reviewers said it would be a book best suited for university, and I agree wholeheartedly -- it would make a decent textbook for those MIS programs brave enough to tackle CM. While in the minds of many that translates to "unsuitable for the real world", I would prefer to offer the following analogy, at the risk of sounding too self-referential. As of this writing, I've reviewed three CM titles. If they were about cooking instead of CM, here's how they would map: Hass's CM Principles and Practice --> A Survey of Current Cooking Methods and Techniques (e.g. Frying, Basting, Folding, Mixing, etc.) Moreira's SCM Implementation Roadmap --> Betty Crocker Cookbook Kenefick's Real World SCM --> Screenplay to "Hell's Kitchen" or maybe "The Galloping Gourmet" (for those who remember the '70s) General commentary aside, I'd like to offer the following suggestions for the next edition: 1) Clarify the term "event registration" on pp. 20-1. I'd also like to say I disagree with the author's view that event registration and change requests be kept as separate entities. A CM program will become hopelessly bogged down in maintaining separate event and change logs. 2) Change the term "person responsible" on pp. 146-7 to "configuration manager" -- it's easy to want to use a generic term to avoid confusion, but it's not warranted in this context. 3) Switch Chapters 12 and 13, to maintain progression of scale. 4) On page 225, what is the meaning of the word "louse"? Does the author mean "bug"? 5) Clarify the term "balance point" on pp. 302-3. To sum, the book has a broad reach, with a useful bibliography, but by itself will not suffice for implementing CM at your company.