Customer Reviews

AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis

5 star:		(15)
4 star:		(7)
3 star:		(4)
2 star:		(7)
1 star:		(9)

 

 

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.

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.

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

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

Printed in 1998 this book is likely to have been in the works in 1996-1997, the very beginning of the patterns movement. A scientifically important step, possibly, but not worth the book. A tendency to find patterns in everything (Golden Hammer is it ?) has played a cruel joke - the book is an anti-pattern in itself.

All that you will learn by reading this book is that software development is in big trouble and nothing could save it. Projects are managed bad, systems are designed bad, code is written bad. But what's the force behind that ? Human nature, that's what ! Seven sins literally are being blamed for the software problems.

Look, I _fully_agree_, but what's the point in finding the funny called patterns in human behavior ? It sure happens in all industries (patterns themselves came from architecture after all), and shouldn't we be reading psychology instead ?

Now, let's see, how the (IT) books should not be written no matter what:

- No observable structure in content, on either book, chapter or page level. So much dust, nothing sticks.

- Written by a committee of admittedly high professionals, this book is ignorant to the audience. Names for the patterns are likely to be taken from their own academic environments, and not only they frequently have no universal meaning (ex. Lava Flow or Cover Your Assets), but worse - the reader is expected to know the English folklore of rather specific sort. As I'm not a native English speaker, I wouldn't know what a Blowhard Jamboree (or The Grand Old Duke Of York) is unless I look in the dictionary. And what are the chances that I come up with this name later when I need to recall the familiar looking anti-pattern ?

- Layout and formatting looks like it's been quickly put up and had no designer to it. Tables and diagrams that look similar or identical although the underlying matter they are explaining is completely different. Pictures are ugly (although comical) and share no style.

- The appendix dictionary of patterns following the book contains, say, 50 assorted items coming from different areas and they are put in alphabetical order for God's sake.

There probably are better anti-patterns books by the time of this review, then you'd better get them instead.

BE WARNED:

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

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.

A noble effort, but this book fails to sufficiently build upon existing literature. Steve McConnell's _Code Complete_ and _Rapid Development_ do a better job covering similar material. The gang of four's patterns book was far more readable. This book attempts to collect, summarize, and name information from many sources, but the value of the collection is far less than its constituent elements.

The book wastes pages. Antipatterns appear on pages 73-267: pages 3-72 are spent on multiple summaries, templates, and fluffy and repetitive rationalizations for antipatterns. I bought the book: stop selling past the sale.

The writing is verbose and repetitive. The authors use jargon and undefined acronyms (so many acronyms appear within the text that an acronym glossary is included at the end of the book). Some readers may enjoy such style, but I prefer English. Another author could have done twice as much with half the pages.

The goal is a good one: create a common taxonomy for common mistakes. Wait for a better book to achieve this goal.

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.

AntiPatterns is a book that needed to be written. It deals with patterns in (legacy) software that are destructive, and how to try to modify that software to improve it. (I include all poorly engineered software in the category of "legacy," regardless of whether that software is now in the developmental stage.)

The lack of serious engineering in much modern software is tragic, and a topic which is not politically correct. But for all programmers who are not "code prostitutes," it is a subject which will impinge on your future happiness and satisfaction on the job.

Although generally helpful, I would like to see the subject matter improved to catalog the most common design and algorithm foul-ups, and specific corrections. (Combine antipatterns with 0-0 design patterns.) Short checklists of the most efficient or powerful algorithms (to date) for solving certain problems, would be eye-opening for most programmers, as the most efficient algorithms for many jobs are never encountered until graduate level CS studies (and so the average programmer doesn't know that they exist).

Hopefully, there will be many more books written on this subject.