I’ll be the first to admit that I’m an object geek. But sometimes good ideas from the object community get lost because they are wrapped up in the mystique of objects. Consider the architecture anti-patterns described in AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis or the Portland Pattern Repository. The purpose of an AntiPattern is to document a bad solution to a common problem, explain how people can slide into an AntiPattern, and mention ways to avoid or remedy it. The point isn’t so much to say "don’t do this"as it is to say "you probably don’t even realize that you’re doing this, but it doesn’t work, and here are some things you might do to fix things."In a recent workshop I conducted for architects working for a state agency, I presented the ideas of anti-patterns to this veteran group of developers. We had a great time identifying anti-patterns they encounter and deal with on an ongoing basis. Most of these architects were not using object technology, but they could spot good decisions gone bad when they saw them. We discussed several examples of Lava Flows, why they occurred, and why sometimes it may not even be a good idea to clean ’em up. What if your code is subject to changing legislative regulations? Arguably, it may be easier to leave in some code than always be shuffling things around. Especially if you are living with a shrinking budget and staff. On the other hand, if you can cut out bad practices and eliminate confusion of why that “three hundred byte record” is there, removing a lava flow can make it easier on the architect who doesn’t repeatedly explain how to step over it to new staff.

I’m on the look out for object biases in the way I talk about design. I’m hoping to bridge the divide between “those in the know” and “those in the know who use objects.” We have much to learn from each other.