AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis [Paperback]

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

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

- This book is on process and *NOT* architecture.
- It is for managers and not for developers.
- It concentrates primarily on project management issues.
- The book is filled with personal opinion.
- It is spotted with questionable "anicdotal" evidence.
- It will not save a project in crisis--but maybe the next project.
- Less than half of the book is even worth reading.

Anyone looking for a companion to the GoF Design Patterns book will be *sorely* disappointed in AntiPatterns. This is not a "bad apples" version of architecture patterns. Instead, it devotes itself to describing symptoms resulting from failed or missing processes. As far as being a process book, it's barely average. It has some good insights and might help a manager spot emerging problems, but much of the advise is too generalized to be of much applied use.

You can tell that this book was written by four seperate people. One of them did an outstanding job (making about 1/4 of the book 5 stars). He describes solutions with detail and clarity. One does a decent job. Two of them are clearly jargon blowhards who have trouble completing a thought. Their chapters offer no detailed advice on what action to take but rather generalize and summarize on vague remedies. For instance, "put more money into architecture" is one fortune cookie they offer.

I wish they had a critical eye preview the book and point out all of their holes -- both in supportive argument and in solution description. Often times a paragraph introduces a concept, and the author neither explains it nor offers any futher reading.

The book is spotted with questionable "evidence" supporting their opinions. Here is my favorite quote of the book, "Meeting productivity gains are must more dramatic,... and we have seen productivity gains over 100,000:1." They have seen fifty years of work performed in an hour! Talk about overselling a process improvement!

And don't get me started on their misuse of the term "refactor."