Rating: 
Summary: Great title, awful book
Review: Like Mowbray's other abomination, "Corba Design Patterns", this book has a really catchy title, but almost no meaningful content at all. Save your money and spend your time re-reading GoF. It seems to be the only Patterns book out there that's not a selling snake oil.
Rating: 
Summary: Worthwhile second book on patterns
Review: Like practically all books on patterns I encountered so far this book doesn't lent itself easily to reading cover to cover and its difficult to use as a reference book without knowing what you are searching for. Aside from that its a good but after the GoF book (Gamma et al. "Design Patterns"). You learn even from browsing in it.
Rating: 
Summary: An amazing look at how object orientation is misused
Review: Most people make the transition from C to C++ or to Java with little trouble, if any. If you look at their code, you'll understand why: People figure out clever ways to do C programming in any language -- No person, no discipline, no environment, and no programming language can FORCE you to program in an object oriented way if you really don't want to. So you don't, and you don't reap the benefits of object orientation either, even though you're using an object oriented language... This means your code is not factored properly, this means you don't have re-usable components, this means you don't get the orthogonality and modularity and reduction in program complexity that object orientation promisses. What would such a program look like? It look like hell! It turns out that people misuse object oriented technology in similar ways, forming not "patterns", but rather "AntiPatterns." The AntiPatterns book is like a pathology textbook for software engineering: It helps you identify projects gone awry, what were the basic reasons for the program to have developed the way it did, what are the consequences of such pathological development, and how to fix things. The idea is not to have to do a complete re-write, but to either isolate the working-but-malstructured parts of the program or fix them gently, a small piece at a time, or both. The book will also teach you how NOT to think about patterns and object orientation.
Rating: 
Summary: Fun, sketchy, and abstruse
Review: My experience in reading this book has been very much like: (1) Reading Dilbert -- It's a somewhat fun look at problems all to familiar to experienced developers and managers. (2) Reading someone's viewgraphs after missing the presentation -- The authors attempt to catalog the AntiPatterns, so many ideas are presented in bulleted form. Buzz words are perhaps overused, too. (3) Reading the Bible -- Many sentences are just too abstruse for me. A lot of effort is required to get the (apparently) *deeper* meaning. The book's greatest, lasting value will be in codifying the many recurring software development problems, and establishing a vocabulary for discussing them. I hope a later edition will correct some of the recondite language.
Rating:
Summary: A good start
Review: Now that Design Patterns have been in the main stream for a decade or so, the idea is ready for rejuvenation. "Antipatterns" does a good job at its part of that update. The full analytic technique should include
-- patterns (what works well)
-- antipatterns (what fails miserably, sooner or later), and
-- refactoring or reengineering (connecting the two). So far, that trio hasn't been put together in a systematic way. This book is a fair first stab at the list of common offenders, though. It has an exploratory style - it distinguishes major and minor (mini) problems, while trying out different ways of expressing evils of different scales. It proposes a systematic way to diagnose each problem, identify causes, and overcome the problem that left the mess in the first place. This is all good, even if Brown et al. haven't left the study in its final form. This book may have lasting value, if only because it's the first to use the "patterns" methodology in studying what not to do. It's good for beginners who haven't seen the messes first-hand, and good for experienced developers who want to systematize their scars and war stories.
Rating:
Summary: A good start
Review: Now that Design Patterns have been in the main stream for a decade or so, the idea is ready for rejuvenation. "Antipatterns" does a good job at its part of that update. The full analytic technique should include
-- patterns (what works well)
-- antipatterns (what fails miserably, sooner or later), and
-- refactoring or reengineering (connecting the two). So far, that trio hasn't been put together in a systematic way. This book is a fair first stab at the list of common offenders, though. It has an exploratory style - it distinguishes major and minor (mini) problems, while trying out different ways of expressing evils of different scales. It proposes a systematic way to diagnose each problem, identify causes, and overcome the problem that left the mess in the first place. This is all good, even if Brown et al. haven't left the study in its final form. This book may have lasting value, if only because it's the first to use the "patterns" methodology in studying what not to do. It's good for beginners who haven't seen the messes first-hand, and good for experienced developers who want to systematize their scars and war stories.
Rating:
Summary: Better idea than execution
Review: OK, i *know* i'm going to get beaten up for picking on a classic like this, but i just did something most people i know who own this book never do - i read the whole thing cover to cover. And here's what i learned - the authors are not very intelligent, the book is hopelessly biased towards the author's preferences (OOP and extreme programming; it also seemed CORBA heavy, but i'm not sure they actually implied CORBA was the best), the format or the way they used it was worthless, most of the points they make are unjustified (and wrong) assertions and the authors love to talk about things they have no background or experience in (a good chunk of the book is spent in an amateurish attempt at psychology, telling you about the personal insecurities and what not of people you don't like) Bottom line, after reading this, there's nothing you can really do to change your projects or your software i don't expect you to believe me, so let me quote some pieces of the book Problem: email is bad because it puts things in writing. Solution: don't use it for criticism. Quote: "e-mail discussion groups send dozens of postings on all kinds of topics, including the trivial and nonessential. These lengthy discussions are time-consuming and labor-intensive." Antipattern: Irrational Managment. Refactored Solution: Rational Decision Making. Quote: "the manager may have... personality limitations that cause them to be ineffective or irrational managers... Refactored Solution... 1. Admit you have a problem and get help." Antipattern: Functional Decomposition. Refactored Solution: Object Oriented Reengineering. Symptoms and Consequences: "- An incredibly degenerate architecture that completely misses the point of object-oriented architecture. - No hope of ever obtaining software reuse. - Frustration and hopelessness on the part of testers." Causes: "- those who generate specifications and requirements don't necessarily have real experience with object-oriented system." And so on and so on. Of course, if you don't see the problems in the above and think these are perfectly intelligent, realistic, constructive, actionable things to say in a book on how to improve software, then maybe this is the book for you On a final note, the title of the book "Antipatterns - Refactoring software, architectures and projects in crisis" sounds like it applies to all systems development. Instead, the book is 100% focused on OOP. OOP is good, but i would have made that obvious on the cover so you know what you're getting. Hate to recommend this to people writing or maintaining VB, COBOL, ERP, CRM or other systems only to have them learn that there's nothing they can do with it
Rating:
Summary: An enjoyable, usable guide to project management
Review: Perhaps the title of this book is unfortunate, given the fact that those who have posted bad reviews here seem to have expected it to be an extension of the GoF Design Patterns book. (In which case they would have been better off with the GoV A System of Patterns book.) All such expectations aside, however, this book is an enjoyable guide to project management that is well worth reading. As for the criticism that it is nothing more than common sense packaged as wisdom, I would argue that common sense is nothing more than applied wisdom, and the common sense this book aims to teach is sadly lacking in too many companies today (hence the existence and popularity of Dilbert). BTW, the reviewer who attributed the quote, "there is nothing new under the sun" to Shakespeare might be amused, given the nature of the quote itself, to find that it was originally written by Solomon (in Ecclesiastes 1:9), quite some time prior to Shakespeare! There is nothing new, indeed.
Rating: 
Summary: Read "Design Patterns" first.
Review: The first few chapters are useless. The antipatterns are ok, but are somewhat too general, factored solutions are not described very well, and examples don't illustrate well. I recommend reading "Design Patterns". This book is optional reading.
Rating:
Summary: DO NOT BUY THIS BOOK!
Review: The material in this book is unbelievably superficial and reeks of the authors' pretentiousness. It is referenced frequently in the pattern literature, but don't go anywhere near it. If you think taking two pages to explain that confrontational e-mails are bad constitutes a 'pattern' then go right ahead. Otherwise, DO NOT BUY THIS BOOK!
| 
