Reuse pattens and antipatterns

My second panel next week is Patterns and Antipatterns: Reusability Hits Prime Time. To be honest, I had to look up the term "antipattern." Google's first result was: "AntiPatterns are an exciting new form of expert software knowledge, a Dilbert-like extension to design patterns." Nice tagline! 1 Ward Cunningham's Wiki describes "antipattern" this way:

An AntiPattern is a pattern that tells how to go from a problem to a bad solution. (Contrast to an AmeliorationPattern, which is a pattern that tells how to go from a bad solution to a good solution.)

A good AntiPattern also tells you why the bad solution looks attractive (e.g. it actually works in some narrow context), why it turns out to be bad, and what positive patterns are applicable in its stead.


Accordingly to JimCoplien: an anti-pattern is something that looks like a good idea, but which backfires badly when applied.

It's not fun documenting the things that most people agree won't work, but it's necessary because many people may not recognize the AntiPattern.

In the old days, we used to just call these 'bad ideas'. The new name is much more diplomatic. [PortlandPatternRepository: Anti Patterns]

In InfoWorld's recent programming survey, we asked some questions about software reuse. Developers were quite sharply divided in terms of their satisfaction with the level of reuse they achieve:

They were also sharply divided in terms of the perceived obstacles to reuse:

I wish I could follow up with more questions. How much of the source of satisfaction lies on the producer side of the relationship -- that is, in the design strategies, tools, and frameworks that make it possible to package software for reuse? And how much lies on the consumer side -- that is, in the determination and skill required to ferret out and apply that which is available to be reused? Likewise for dissatisfaction: how much is methods and tools, how much culture and behavior?

The response to our question about the relative benefits of different flavors of reusable software could also use some unpacking:

For a long time, I've thought that what I call the components-and-glue pattern is the ultimate recipe for effective reuse. In this pattern, relatively few systems programmers (who create kernels, libraries, and components in "hard" languages) support relatively many application developers (who use these kernels, libraries, and components from "soft" languages). I've also assumed that pattern would iterate one level up: relatively few application developers packaging idioms ("solutions") for relatively many power users to customize and apply. The progression shown here could be interpreted as suggesting that reuse thrives best on the forest floor, not up in the canopy. Is the democratization of reuse perhaps an antipattern? Good question for the panel. If you'd like to suggest other questions, please do.

1 Because used <meta name="description" content="...">, Google coughs up that nice pithy phrase instead of whatever random stuff it would otherwise glean from the page. Heh. How did I never notice that pattern before?

Former URL: