Rating: 
Summary: Very nice book, enjoyable and instructive
Review: Being able to identify and name key problems in a software project is as helpful (if not more) as being able to design it well. This book provides common problems grouped in an easely accessible manners (ala Patterns). Those seeking a way to share common knowledge about software problems should look into AntiPatterns, this book is the starting point.
Rating: 
Summary: Let this book be what it is.
Review: I can't believe the number of reviews on this site that compared the book to Design Patterns from GOF. If you bought it expecting the same, write yourself the one-star review. This book does have some problems, but it really does a whole lot of things very well.- It's easy, and fun, to read. The authors expertly inject humor and life into a dead topic. A dull book with good ideas will rot on the shelf. - It provides a fresh, new angle that has value. We programmers do not learn enough from war stories told around the water cooler. - It provides the other side of the design pattern. You really do need both, and this industry needed someone to take a stab at creating a template for antipatterns. Consider health care. You need diagnostics and preventative care. Ditto for auto maintenance. Operations research has been built around building models that work while trouble shooting the kinks in a system. The authors did a noble job of seeing the vacuum and stepping up to fill it. I find it incredible that this book has been slammed for something that it does not pretend to be. If you wrote a one star review because this book was not the second coming of the Design Patterns book, then shame on you. What you will get is a humerous look at some very real problems around software development. The bias is clearly toward project management, and that is a appropriate for a first book on antipatterns. That much was clear to me from browsing the book for a minute or two. Great job, team. If I had a criticism, it would be that the contributions from the four authors were not better coordinated. After writing two books with two additional co-authors each, I can testify that it is a difficult problem to solve. Still, better coordination could have helped. Five stars for the writing style and the concept. That's why this book is a smashing success.
Rating: 
Summary: A book that itself screams for refactoring...
Review: I found some value in AntiPatterns for the comprehensive collection of "common pitfalls" that it describes; but it is otherwise seriously disappointing. Patterns are most readable - and Dark Patterns should be no exception - when they are pared to their barest essentials, to show in stark contrast the conflicting forces which their solution balances. In marked disregard of this meta-pattern, the book's opening chapters, which claim to establish AntiPatterns as "a more effective form of design patterns" grossly overhype the form, and run to an absurd length. In fact, they almost managed to turn me off the notion of AntiPatterns entirely. (I think I definitely prefer the appellation "Dark Patterns" - solutions which *do* work, at least in the short term, but carry unacceptable risks.) The actual AntiPattern write-ups are educational, to be sure, but the writing is often gauche, the "patternity" sometimes unconvincing, the illustrations mostly pointless (Dilbert cartoons excepted, natch), and some of the technical examples quite hollow. To be fair, AntiPatterns is not all bad. The chapter on Management AntiPatterns especially has some saving graces. But the book, overall, appears to ironically fall prey to one of the errors it decries - Design By Committee.
Rating:
Summary: A book that itself screams for refactoring...
Review: I found some value in AntiPatterns for the comprehensive collection of "common pitfalls" that it describes; but it is otherwise seriously disappointing. Patterns are most readable - and Dark Patterns should be no exception - when they are pared to their barest essentials, to show in stark contrast the conflicting forces which their solution balances. In marked disregard of this meta-pattern, the book's opening chapters, which claim to establish AntiPatterns as "a more effective form of design patterns" grossly overhype the form, and run to an absurd length. In fact, they almost managed to turn me off the notion of AntiPatterns entirely. (I think I definitely prefer the appellation "Dark Patterns" - solutions which *do* work, at least in the short term, but carry unacceptable risks.) The actual AntiPattern write-ups are educational, to be sure, but the writing is often gauche, the "patternity" sometimes unconvincing, the illustrations mostly pointless (Dilbert cartoons excepted, natch), and some of the technical examples quite hollow. To be fair, AntiPatterns is not all bad. The chapter on Management AntiPatterns especially has some saving graces. But the book, overall, appears to ironically fall prey to one of the errors it decries - Design By Committee.
Rating:
Summary: Joy and Pain
Review: I picked up this book at one of the few remaining good bookstores that caters to IT professionals and found it an enjoyable read. Some may be turned off by the book as it does contain some highly speculative statements that are not supported by facts. For those who refuse to remove the stick from their XXXX then don't buy this book. For those who want a good read on the IT profession as a whole, then I recommend it. If you enjoy Dilbert, you will enjoy this one as well.
Rating:
Summary: A good idea, a very boring and dissapointing implementation
Review: I was very anxiuos about reading this book. Before of purchasing it, I had already read some info and presentations on the web (c2 wiki, antippaterns site, etc.). I already knew the catalog and i'd like it very much. But the book...what can i say of the book? first of all, I found it quite boring and verbose. The same could have been sayed using half of the words or maybe less... In the book I've found a couple of annoying things:
- The authors quote themselves ALL the time
- The solution to ALL architecture antipatterns (and software as well) includes a reference to CORBA, OMG IDL or open systems...There are more things in the world! What can we, developers in sin, that don't use open systems or corba do?!?!
- They never do quote the GoF work, altough in same cases it would be very helpful, instructive and fair. In turn, they quote to their CORBA patterns book
- They only quote the GoF to say that their patterns are complex and that antipatterns are easier and funnier. Couldn't disagree more on this!
- There are some contradictory ideas throughout the book
- They are doing themselfs in some of the antipatterns (I would not say which ones, but after a quick read is easy to guess ;))
- The second chapter, the reference model, is very boring and with lots of unnecesary rethoric
- In fact, all the book is full of unnecesary and unpleasant rethoric stuff
- After reading the book from cover to cover, I realized that just reading the "Appendix A" I would had enough
- The name of the book is tricky. They don't say nothing about CORBA, but inside the book they say that this is the companion book of "CORBA Design Patterns"
- Many of the solutions are biased
- Their concept about refactoring is quite "fuzzy"... There are some good points on the book:
- The catalog is quite interesting.
- Some patterns are nicely developed and fun to read
- Being familiar with the catalog allows to find easily antipatterns in everyday work
- The final appendix is a very nice compilation that offers a good view to the catalog Anyway, the point is: don't buy this book. You can get the same in the web for free, saving money and time
Rating: 
Summary: Skip it - poorly written; little substance
Review: I've gotten a lot of milage out of the GoF Design Patterns book, but like many people, I have seen software where design patterns were applied inappropriately. I was looking for a book that explored some common pathologies of Patterns-based design and suggested appropriate refactorings to overcome them. Sadly, this book is not the one I was looking for. Large amounts of the book are filled with mindless jargon, or would be better aimed at managment consultants than software engineers. The authors have a bizarre obsession with CORBA, and several of the "antipatterns" seem to be little more than a personal rant about failed CORBA projects the authors have been involved with. Worse, the antipatterns that discuss software rather than organizational issues are often so poorly written that they are useless. Often they are written in such vague language that you can't figure out what type of system is being discussed. The problem is compounded by facile examples that don't clearly illustrate the problem or the possible solution. The authors can't even manage a clear definition & example of "Spaghetti Code", which any 1st year engineer has probably encountered. SAVE YOUR MONEY. I'd recommend reading GoF's Design Patterns and Martin Fowler's Refactoring instead of this book.
Rating:
Summary: My New Favorite "Work" Book
Review: If only all the compter lit I have to read was this great. Some guys in class said it's just a "rehash of well-known computer mistakes like Spaghetti Code." I don't think they read it, because it also helps you *fix* them. Besides, someone *needed* to formalize these terms so everyone knows exactly they mean. For example I have a major "lava flow" anti-pattern happening on my thesis project right now -- wish I'd read it before I started!
Rating:
Summary: An insightful look at problems generically
Review: If your company's walls are littered with Dilbert cartoons, then there's a strong possiblity it can benefit from this book. AntiPatterns classifies, in serious tone but approachable language, generic problems that get in the way of success. After taking a strong look at the root issues, it help to formulate workable solutions to those problems. I found it to be well organized and uncannily familiar.
Rating:
Summary: How to avoid a rut in software development
Review: In 1994, a book was published that caused a mini-revolution in the field of software development. The book was _Design Patterns_ by Gamma et. al. Their approach was to describe software in terms of patterns, which are abstractions that are more general than a standard algorithm. Since that time, a small but growing band of individuals have made great progress in the codification and application of patterns. Preliminary indications are that properly understood, and it is problematic that anyone really does at this time, and applied patterns will have a substantial affect on software development.
An antipattern is a pattern that has negative consequences when applied. This ranges from the antipattern that almost always leads to a negative consequence to those that are generally positive, but lead to negative results when used in the wrong context. One example is the Cut-and Paste Programming antipattern. We all have benefited from the use of cut and paste and we have all suffered when we used it in an inappropriate situation. Many such examples are given, and fortunately for us all, for each antipattern the authors provide instructions on how to recognize it, what causes it and how to cure it. Anyone who has worked in software development has experienced one or more of these problems.
In keeping with a negative often being more significant than a positive, it is quite possible that the study of antipatterns will yield more substantial results than similar effort being expended elsewhere. That is why I included this book in my list of best books of the year that appeared in the September, 1999 issue of _Journal of Object-Oriented Programming_.
| 
