Anti Patterns: Refactoring Software, Architectures, and Projects in Crisis by William J. Brown, Raphael C. Malveau, Skip Mc Cormick, Thomas J. Mowbray
images.amazon.com
[ISBN: 0-471-19713-0] The authors use several big vendors' technologies as examples of today's antipatterns. Luckily, they suggest ways to overcome antipatterns and improve software productivity in "refactored solutions" that can overcome some of these obstacles. However, this is a realistic book, a mix of "Dilbert" and software engineering. A clever antidote to getting too optimistic about software development, Anti Patterns should be required reading for any manager facing a large-scale development project. -- Amazon Review
Wards Wiki Reviews:
Lists some interesting architectural, development, and management Anti Patterns. But it has a lot of fluff and not enough meat, in my opinion, which is not universally admired. Wait for it in paperback, or treat it as "one to scan." -- Ron Jeffries (who gives it 3 out of 5 possible stars in his review on amazon.com)
On the web site you'll find a tutorial (as given at OOPSLA '98) and some examples.
Unconvincing, the illustrations mostly pointless (Dilbert cartoons excepted, natch), and some of the technical examples hollow.
Laurent Bossavit -- Just finished it. I found some value in it for the comprehensive collection of "common pitfalls" that it describes; but it is otherwise seriously disappointing.
The opening chapters, which claim to establish Anti Patterns as "a more effective form of design patterns" grossly overhype the form and in fact managed to turn me off the notion of Anti Patterns entirely. (I think I definitely prefer to call them Dark Patterns: solutions which do work, at least in the short term, but carry unacceptable risks.)
The writing is often gauche, the "patternity" sometimes unconvincing, the illustrations mostly pointless (Dilbert cartoons excepted, natch), and some of the technical examples hollow.
It's not all bad. The chapter on Management Anti Patterns has some saving graces. But the book, overall, appears to ironically fall prey to one of the errors it decries - Design By Committee.
Jeff Grigg -- I liked the book. It's an entertaining read. It does assign nice names to things you may well find in code. (Come to think of it, I loaned it to a project manager recently. He liked it too, but hasn't returned it!!! I'll have to go give him a hard time. ;-)
A list of development, management and architecture anti-patterns in this book now appears on the Anti Patterns Catalog page.
It contains some Anti Patterns not in the book, but isn't that only to be expected in an interactive, collaborative space such as Wards Wiki?
See original on c2.com 