Anti-Patterns and Patterns in Software Configuration Management

Rating:
Summary: Easy Read
Review: An easy skim which serves as a decent reminder of the importance of SCM. It highlights some areas for attention, and provides some tips. Most of the scenarios should be familiar. Its usefulness is that it may reach a broader audience than a textbook, so you can pass it around for discussion.

Rating:
Summary: Not on par with their last work
Review: Sequels are tough. The original AntiPattern book was light, funny, and right on the mark. It was a tough act to follow. This offering, that shares a couple of the same authors as the original AntiPattern books, falls short.

There is a hint from the authors themselves that this isn't a seminal work. The preface tells readers they can hunt for their particular antiPattern but "We suggest that it is better for you to read through the entire book now (it's not that thick)". Indeed it is not. At just over 300 pages, it is formatted such that about 1/3 of that space is either blank or large cartoons and pictures. So, while it might appear to have the same "heft" as the original, looks are deceiving.

The book suffers from two major problems: a lack of depth and poor editing. The original antiPatterns book is cited no less than 18 times in this work. Borrowing from past efforts and quoting yourself isn't necessarily bad--but it isn't a substitute for new material. Curiously, Steve McConnell (Code Complete, Rapid Development, etc.) is quoted almost as many times--far more often it seems than any other reference. There is an entire industry to draw from. Why such emphasis on just two sources?

Finally, the editing is dreadful. Terms and acronyms are introduced without definition and the general flow of the text is awkward much of the time. This book needed an editor!

Because there is so little written on CM from a management perspective I'm inclined to give the work 3 stars instead of my usual 2 stars for a flawed work. While there certainly are problems with this book, they fall mostly into the category of "missed opportunity" instead of erroneous information.

Rating:
Summary: No big shakes yet helpfull
Review: Sometimes a book only confirms the things you already knew, either consciencly or subconsciencly. This is not necessarely bad. I you run into a customer that violates every good practice that you're aware of, you can use the book to convince your customer that he's wrong and you're right. After all, all good ideas look a lot more impresive when they are printed.

Apart from that, it's fun reading.

Rating:
Summary: More helpful than most SCM books
Review: The software development community desperately needs a good, readable book on Software Configuration Management (SCM). SCM is poorly understood in the development community. Sometimes it seems as though there is no faster way to make the eyes of developers, project managers, and executives glaze over than to mention SCM. Yet SCM is terribly important to the process of developing and maintaining software products.

I purchased the book based on a quick glance; it looked friendly, and I was particularly attracted by the authors' claim to have modeled their work after Christopher Alexander's superb book "A Pattern Language". Yet they seem to be oblivious to the all of things that make the A Pattern Language a great book. In particular, A Pattern Language is organized tidily, written concisely, and explained clearly. AntiPatterns and Patterns in Software Configuration Management is none of these.

If one looks around, one can find anti-patterns in lots of bad books on computer software development. Here are some of the anti-patterns that I found in Anti-Patterns and Patterns in Software Configuration Management.

Disorganization: The Patterns and AntiPatterns are subject to similar descriptive templates, which include Background, General Form, Variations, and Examples. As a result, it is often unclear as to whether the authors refer to the problem or the solution. If you read the "Background" section on page 276, one of the authors describes the inspections that he was required to perform while in the Navy. Yet this passage is intended background for an AntiPattern, so I was confused as to whether the author was praising or disparaging the practice.

Misuse of Icons: AP&P contains icons to highlight the items related to a given pattern or anti-pattern. A pattern is a good thing; an anti-pattern is a bad thing. Why, then, is the icon for the General Form of an Anti-Pattern (a bomb with a lit fuse) the same as the icon for the General Form of a Pattern (also a bomb with a lit fuse)?

Inflated writing style: "[System engineering is] an application of necessary effort to transform a required operational capability into a set of parameters defining performance and function, using an iterative process of analysis, synthesis, specification, design, and test to result in a final conclusion." This sentence is not one of the worst in the book -- the sentence is merely typical -- but I defy anyone to read the sentence and to comprehend it on the first go-round. (Isn't software engineering more than simply defining parameters? Isn't there some sort of product that software engineering is supposed to deliver? What form of conclusion is not final?). One of the categories in the AntiPattern template is called "Refactored Solution"; when one has just finished describing a problem, what's the difference between a solution and a refactored solution? Software projects are often called "developments" in this book -- why?

Unrelenting use of the passive voice: The authors regularly use the passive voice in the book's examples. Take page 188: "After several delays due to recoding and retesting, it was decided to refine the process to cover the missing parts of the development lifecycle." Who decided? "Specification design was implemented for interface specifications for each component." Who implemented the specification design (or who designed the interface specifications, or who specificied the implementation)? Moreover, wouldn't it be just as simple to say "Interface specifications were designed for each component?"

Awkward sentence construction: "Critical to the effectiveness of any software configuration management organization is a strong definition of how software configuration management is implemented within the greater organization." (page 56True. Annoying to the reader are sentences that begin in their own middles. Run-on sentences, and misrelated pronouns can be found on practically every page. Here's another example, from page 22. "Millions of lines of code have forced SCM to the forefront of the system lifecycle disciplines, because without SCM, many projects fail, or the costs become exorbitant to deploy." It is the need to manage millions of lines of code is what has forced SCM to the forefront; the lines of code don't do anything on their own. Projects are sometimes deployed, but I have yet to see a cost deployed, exorbitant or not.

Shoddy copy editing: "Annecdotal (sic) evidence: Often-heard phrases and comedic material are (sic) associated with this AntiPattern." (page 9). A professionally edited book should not contain two obvious errors in a single paragraph. In this case, those errors are the misspelling of "anecdotal" and the superflous word "are" (which makes nonsense of the intended explanation).

These complaints may sound like nit-picking; they aren't. The poor writing and editing in this book detract from its clarity, add to its length, and reinforce to the mistaken belief that SCM is dull or hard to understand. On top of that, there is little practical advice in the book, other than motherhood issues -- it's a good idea to plan a project; it's a good idea to plan before you implement; configuration management staff can sometimes go overboard; that development teams should keep not only source code, but all of the documents associated with a project under version control. There is a hearty thank-you to the editor of this book in the Acknowledgements section; I cringed as I read it.

Beware of writers that attempt to faciliate comprehensibility by the utilization of enhanced linguistic schema (or rather, beware of writers that try to make themselves clear by using big words). By any means possible read "A Pattern Language", but wait for some future, greatly-improved edition of "AntiPatterns and Patterns in Software Configuration Management."

Rating:
Summary: Great for identifying problems and potential pitfalls!
Review: This is an interesting, informative book on potential problems and pitfalls to be encountered in the wild world of Software Configuration Management! For those who want a step by step guide to implementing SCM at your company, look elsewhere, but if you want to know why your SCM initiatives are failing, or what problems lie ahead on the road, this is the read for you!