Anti-Patterns and Patterns in Software Configuration Management (Hardcover)

~ (Author), Hays W. McCormick (Author), Scott W. Thomas (Author)

Editorial Reviews

Review

I first heard the term antipattern while reading AntiPatterns Refactoring Software, Architectures, and Projects in Crisis, the first book in this antipattern series (John Wiley & Sons, 1998). I was curious about the term's relation to the concept of a design pattern but soon learned that the main point is understanding which part of a pattern definition relates to the prefix "anti." As the book explains, "An antipattern is a literary form that describes a commonly occurring solution to a problem that generates decidedly negative consequences."

Antipatterns clearly define frequent mistakes in software projects and provide solutions. The books in this antipatterns series (which should be read in order) are a result of the authors' attempt to categorize, label, and describe recurring situations in software development that have negative consequences. While the first book comprises 18 antipatterns divided into the three parts according to three different viewpoints software development, architecture, and management the second book, AntiPatterns and Patterns in Software Configuration Management, aims to help management. Managers of software development projects must understand software configuration management (SCM) methods and techniques, and the authors provide the necessary knowledge and experience using antipatterns and patterns." - IEEE Software

Product Description

Antipatterns are an emerging and controversial new area in the patterns community. Where design patterns identify different types of procedures, designs, or code that worked in object-oriented projects, antipatterns target those common mistakes, defects, errors, or difficult people that can sink object-oriented projects and systems. Configuration Management (CM) is managing the evolution of a software project - managing the revisions or changes to the product after it is first released. This phase is important in a product's ongoing life-cycle because CM helps to ensure that all improvements are implemented in a timely and accurate fashion. In addition, CM ensures that product testing occurs and is accurately documented so that the test findings can be incorporated into improving the design of the product with the next version. This book continues where the first book on antipatterns by this author team left off. In the first book, they focused on the areas of design, architecture, and management, in other words - people issues. With this book, they focus on the area of Configuration Management and document over 20 antipatterns and ten design patterns that exist during this stage of a product's development.

See all Editorial Reviews

Product Details

• Hardcover: 336 pages
• Publisher: John Wiley & Sons (April 23, 1999)
• Language: English
• ISBN-10: 0471329290
• ISBN-13: 978-0471329299
• Product Dimensions: 9.6 x 7.7 x 1 inches
• Shipping Weight: 1.7 pounds
• Average Customer Review: 3.0 out of 5 stars  See all reviews (7 customer reviews)
• Amazon.com Sales Rank: #386,860 in Books (See Bestsellers in Books)

Customer Reviews

Most Helpful Customer Reviews

37 of 39 people found the following review helpful:

1.0 out of 5 stars We need good books on SCM. This isn't one., July 28, 2000

By	Michael Bolton (Los Angeles, CA USA) - See all my reviews

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."

23 of 23 people found the following review helpful:

3.0 out of 5 stars Not on par with their last work, January 26, 2001

By	B. Scott Andersen (Acton, MA USA) - See all my reviews (REAL NAME)

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.

12 of 13 people found the following review helpful:

4.0 out of 5 stars More helpful than most SCM books, August 31, 2000

By A Customer

After reading these guys' first book (AntiPatterns - which I liked a lot) I was hoping to find this one as much fun to read, and as insightful. I also knew that, as a SW pro, I needed to get smarter on SCM (I'd been avoiding the topic "successfully" and faking it for too long). So I figured it was a no-brainer... As with the first book, I resonated with the material and got a lot from it (I liked the Domino Effect AntiPattern, which my company could be the poster-child for). But this book isn't as entertaining/fun as the first one, and I don't think it was edited as carefully. But it's still great for SW pros who know they aren't really as up on SCM as they should be and just can't get through massive booring "textbooks" that they bought and are still on their bookshelf (I have at least three). It's entertaining enough that you'll get through it, and your sure to see some SCM mistakes you're making or have made and want to avoid. I think their last book was a tough one to follow, and they picked a really tough subject. So my recommendation -- buy it, and read it... it'll help you. Just don't expect it to be as much fun as their first AntiPatters book.