It seems that lately, you can't pick up a book or magazine without hearing about design patterns. If you're new to the idea of design patterns, they're simply time-tested solutions to common problems.

Design patterns began with the work of Christopher Alexander, a PhD in architecture (as in buildings). Alexander noted that certain problems have optimal solutions, and designated these solutions as "design patterns."

Here, Alexander describes design patterns (from his Web site, patternlanguage.com): "For example, if you are building a house you need to go from outside to inside and there are centuries of experiments on how to do this in a 'just so' way. Sometimes the transition is marked not by just a door but by a change in elevation (steps, large, small, straight, or curved), or a shaded path, or through a courtyard. We wrote up this knowledge in the form of a pattern about entrance transitions."

While design patterns got their start in architecture, they were even more successful in influencing the object-oriented programming community. Four brilliant programmers and theorists (dubbed the "Gang of Four") saw analogies between building architectures and software architectures, and decided to document design patterns in software. The result was a seminal work called Design Patterns.

It's not light reading, but it does reward the student with insight into "just so" solutions. Experienced programmers can document the designs they have found to work, sparing learners from repeating mistakes. As they say, a good programmer learns from his/her mistakes, but a great programmer learns from the mistakes of others.

I think the interest in design patterns in the ColdFusion community is great - it indicates that our community is maturing and growing. But this isn't an article on patterns, but one on antipatterns.

An antipattern is just what it sounds like - the opposite of a pattern. While a pattern documents a proven solution, an antipattern documents a proven fiasco. Perhaps the spirit of antipatterns was best captured by the American newspaperman and curmudgeon, H.L. Mencken in this quote: "For every complex problem, there is an answer that is clear, simple - and wrong."

Antipatterns are those clear, simple, and wrong ideas that, in our haste or inexperience, we may find ourselves drawn to. While design patterns provide us with valuable advice on what to do, antipatterns provide us with invaluable advice on what not to do.

Table 1 shows some antipatterns that are not software related to help get you into the spirit.

As can be seen from the Monty Hall antipattern, sometimes the wrong choice just feels right. No wonder, then, that we get suckered into an antipattern. (If you're absolutely sure that I'm wrong on my advice regarding the game show, head over to www.halhelms.com, where I'll try to show you that your intuition is wrong in this case.)

Some time ago, I wrote an article about how to write really bad code, inspired (as I claimed) by the realization that the sheer amount of bad code out there indicated that people really wanted to write bad code, and I stepped up to help them.

While it's fun to write (and hopefully, read) such articles, there is a deeper truth at work. Sometimes, we can learn more from failures than successes. When we succeed, we may not know why we succeed and any lessons we "learn" from our successes may be nothing more than coincidences. We see this caricatured in superstitious people who wear lucky clothing or work through rituals that they have somehow associated with good things happening.

But failure has a way of clearing the mind of such specious associations. Sometimes pain can actually be therapeutic, if it leads us to question our assumptions and be relentless in searching for the truth. That's just where antipatterns can help us.

Some antipatterns are strictly technological while others have broader implications. Look at the real antipatterns shown in Table 2, taken from a Web site devoted to this topic, www.antipatterns.com.

Studying antipatterns tells us about things we don't already know. As my students can attest to, I consider cut-and-paste programming one of the true evils of programming, but I had never considered the solution to the Boat Anchor problem - and there lies the value of antipatterns: they can help us see things in a new light.

Antipatterns are growing in popularity as people find that studying failure can actually lead to success. Among the resources available are these:

http://mindprod.com/unmain.html: This wonderfully written site is both fun to peruse and instructive.

I've been involved in many "post mortems" where the project went wrong - sometimes badly wrong. Too often, these sessions turn into a search for personalities to blame. Why were we late on delivering the software? Because Sue's group was late with the SQL queries! One way out of this ugly situation is to direct the attention of the group toward discovery of antipatterns rather than toward a hunt to punish the guilty.

Years ago, W. Edwards Deming, justly famous for being the "man who taught the Japanese quality," invented a game that, he said, mirrored the quality situation in virtually all American companies. He called it the "Red Bead Game." In the game, thousands of white beads are placed into a drum, and for every nine white beads, a red bead is added, making the percentage of red beads to the total number of beads 10%.

Certain audience members representing workers were given paddles into which 100 indentations had been made. Each indentation held a bead. They were then told to insert their paddles into the drum of beads and withdraw it with the paddle filled with beads. The number of red beads would then be measured. "Quality" was defined as having fewer than ten red beads. The game was played with great gusto, with "managers" inventing quotas and rewarding "good" workers who got less red beads while punishing "bad" workers.

Of course, none of this worked in the slightest since the workers had no control over how the beads fell into the holes made for them. The problem with quality, Deming drove home, is almost never in the people themselves; it is in the system. Or, putting it just slightly differently, there are antipatterns at work that produce bad results.

The same is true with software development. Rather than trying to identify "bad" programmers, we're much more likely to succeed if we identify antipatterns and work together to refactor a solution in which everyone can win.

Published May. 1, 2003— Reads 10,591
Copyright © 2008 SYS-CON Media. All Rights Reserved.

Related Links

▪ Figure 1

▪ Figure 2

About Hal Helms
Hal Helms is a well-known speaker/writer/strategist on software development issues. His monthly column in CFDJ contains his Musings on Software Development and he has written and contributed to several books. Hal holds training sessions on Java, ColdFusion, and software development processes. He authors a popular monthly newsletter series. For more information, contact him at hal@halhelms.com or see his website, www.halhelms.com.

Add Your Feedback

In order to post a comment you need to be registered and logged in.

Register | Log in

Please wait while we process your request...