Title: AntiPatterns Refactoring Software, Architectures, and Projects in Crisis
Authors: William J. Brown, Raphael C. Malveau, Hays W. "Skip" McCormick III, Thomas J. Mowbray
Publisher: John Wiley & Sons, 1998
AntiPatterns are an attempt to catalog the mistakes and practices that contribute to software project failure. Like patterns, AntiPatterns have associated "forces," and consequences. But AntiPatterns go one step further in suggesting ways out of bad situations. AntiPatterns are not exact opposites of the design patterns popularized by Gamma et al . Those patterns describe interactions of software components. By contrast, AntiPatterns are a mixed bag of architectural, process, and human problems. They are typically "implemented" without full awareness of project participants, and they tend to manifest over a period of time, like a slowly growing cancer.
An example of an AntiPattern described in this book is the Lava Flow AntiPattern. You know you're in a Lava Flow pattern if you keep finding old code that doesn't seem to be used anymore, and yet you're reluctant to delete it, because - well, who knows what might break? In the words of the book, "the Lava Flow of obsolete technologies and forgotten extensions leaves hardened globules of dead code in its wake."
This points to another difference between patterns and AntiPatterns, and the difference shows up clearly in this book: AntiPatterns are more fun to read about, especially if you're not in the throes of one yourself. AntiPatterns also tend to have humorous names. Some of my favorites from the book are The Blob, The Corncob (referring to a person), and Death by Planning. It would be a mistake, however, to conclude that this book was a high-minded spoof of the Patterns movement. The authors are true believers in Patterns, and they are serious about patterns and AntiPatterns alike.
The purpose of this book is to help you see when you have entered the gravitational field of an AntiPattern, and to show you how to get out before your project spirals into oblivion. The book describes 18 major AntiPatterns (and even more "mini AntiPatterns") in three categories: software development, software architecture, and software project management. All three sections make for interesting and entertaining reading.
AntiPatterns introduce a feature not found in plain old patterns: the refactored solution. In software, refactoring involves rearrangement of code, but the refactored solution refers to a much broader concept. In fact, I'd say a little too broad, but more on that later. A refactored solution might involve anything from rearranging class hierarchies to acquiring new technology. It is something that opposes the ill effects of the AntiPattern, either by prevention or as an antidote.
Eat Your Peas
Some AntiPatterns are actually good patterns gone bad. This can happen when zealous new believers try to apply a pattern where it doesn't fit. A pattern applied in the wrong context becomes an AntiPattern. Maybe that's why the authors take such pains to set the proper context before describing AntiPatterns in detail. (An AntiPattern can also be misapplied, after which it becomes, I suppose, an AntiAntiPattern.) So the first four chapters of this book focus on the nature of patterns, of AntiPatterns, and how they relate to software development.
The authors are really attempting two things here. They want to set the context for AntiPatterns, and they want to remedy some problems that plague patterns in general. A couple of problems identified in the book are difficulty in finding the appropriate patterns, and difficulty in assimilating them once found. The authors' solution includes an elaborate, layered, software development model, and a near-dictatorial insistence on the use of patterns templates to separate the wheat from the chaff. Beyond that, this first section reads pretty much like any book on software project management. You encounter models, principles, theory, an anecdote or two along the way. I feel duty-bound to tell you to "eat your peas" - you probably shouldn't skip these chapters. But it's hard to resist moving on to the fun stuff.
Some Words about Words
I like this book, but I don't like its potentially corrosive effect on the English language. For starters, this book has appropriated a perfectly clear word, refactoring, and hitched it to a perfectly vague concept, the refactored solution. The reason this term gives me such heartburn is because it seems to promise a lot more than it delivers. Some of the AntiPatterns described in this book clearly have no solutions, once you're in the thick of them, beyond starting over. In these cases, the "refactored solutions" offered are merely preventive, and in fact may have nothing to do with any kind of refactoring as we know it. So if this book becomes popular, look for "refactoring" to become another buzzword - a euphemism for "we're trashing everything and starting over from scratch."
I always groan inwardly when some new vulgarism makes its way into the language. Until I read this book, I thought gaudy concatenations like "AntiPattern" were safely confined to press releases and source code. No more. Now we must all deal with four forms of compound words (antipattern, anti-pattern, anti pattern, AntiPattern). If I edited a dictionary, I think I'd jump off a bridge.
One final complaint, and then I'm done. This book repeatedly cites a study claiming five of six corporate software projects are failures. That's an astonishing number, until you figure out that "failure" can also include going over budget or missing a scheduled completion date. I hardly think a programmer who had sweated blood on a project would appreciate such a dismissive assessment.
Indeed, the authors are a mighty grim bunch when it comes to software development, but at least that keeps them from indulging in too much hype themselves. They justly point out the failure of past revolutions - structured programming, open systems, OOP, etc. - to create a software heaven on earth. It is sobering to realize that each of these paradigms, in its own time, seemed to hold the answer to all our problems.
How to Use This Book
I think that if you read this book, you can't help but absorb some general programming wisdom. But I can see two specific ways this book can be helpful to programmers. If you sense that the project you're on is headed for the sewer, this book will help you articulate what's wrong to your project manager. That could make a remarkable difference in how things turn out. If you are a lead programmer or manager, imbibe this book as a good stiff dose of preventive medicine. Maybe you can avoid becoming a statistic for Edition Two.
Marc Briandis Editor-in-Chief of C/C++ Users Journal. He loves programming, writing, and too many other things for his own good. However, he hates to work, which is why he is an editor. He may be reached at email@example.com.