Thomas J. Mowbray

1 out of 5 is the score I reserve for books that I consider a waste of my reading time. It saddens me to say so, but this book deserves that score. AntiPatterns has an excellent premise: just as there are good patterns which benefit the development process, there are also bad patterns. These negative patterns can be at many levels including the level of code, the level of architecture, and the social level. As anyone who has been on a real project knows, there is plenty of material for a book with this premise. Sadly, despite the occasional glimmer of interest, this book does not deliver on that potential. Rather, it is dated, boring, and vague.

The book shows its age with frequent references to technologies that, at best, I have but vaguely heard of (CORBA, OMG IDL). Another historical artifact, at least relative to software development at my workplace, is the strict division of architects and developers. Developers, it seems, are naught but the lowly dregs, necessary only because architects cannot dirty their hands with the writing of actual code. In addition to being annoying, this division is unrealistic. In my world, you need both sets of skills, and I believe, from personal and collected anecdote, that those with both perspectives will come to better solutions.

I could forgive the dated references and social structure if the book were otherwise interesting. I quite enjoyed The Mythical Man-Month despite its age. However, this book was boring. The authors used a distinctly academic style. As a reader, I don't care about the general development of the field of software patterns. I don't care to read in excessive detail about who else may have named a similar antipattern or why the authors think their version is better. I want substance.

And yet, substance rarely appeared. Comically, although perhaps understandably given how definitions drift over time, the authors called the solutions to their antipatterns the "Refactored Solution". But the solutions were generally vague and unactionable. For example, one antipattern is "The Blob", that class that does everything and is the heart of your application (yup, I'm familiar with that one). The suggested solution: find cohesive components, move them into other places if such places exist, otherwise create such places. Poof! You're done. As if it's that simple.The coupling within real blobs is deep; without a description of how to manage that complexity, the refactored solution does not go beyond common sense. The other antipatterns follow this same pattern: a description of a very real problem is followed by a worthless solution.

I did get something out of this book: as with traditional design patterns, one of the best things about anti-patterns is that they name common problems, making them easier to talk about. That said, the 6 page appendix which summarizes all the patterns provides all of that value. As for the rest of the book, it was a waste of time.… (meer)

This book tries to assist in software development, and the management thereof, by providing concrete descriptions of common patterns to avoid. It's most useful to those new to the arena, but even experienced developers and managers will find new angles on old stories here. Plus, it is quite helpful to use as "ammunition" when making a case for the correct way to senior management. As always, having it in black and white adds power to your argument.

That said, if you are experienced and work outside the normal corporate cube farm, perhaps in small teams of carefully selected, competent people, this book won't add much value. It will just make you glad for the career choices that put you in such an enviable position.… (meer)