Digital Edition

SYS-CON.TV
The Power of Antipatterns
The Power of Antipatterns

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:

  • www.antipatterns.com: Good information on the site and links to buy various books on antipatterns.
  • www.bitterjava.com: A Java-centric resource (and book), but an excellent one that can be utilized by developers working with ColdFusion components.
  • 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.

    About Hal Helms
    Hal Helms is a well-known speaker/writer/strategist on software development issues. He holds training sessions on Java, ColdFusion, and software development processes. He authors a popular monthly newsletter series. For more information, contact him at hal (at) halhelms.com or see his website, www.halhelms.com.

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

    Register | Sign-in

    Reader Feedback: Page 1 of 1



    ADS BY GOOGLE
    Subscribe to the World's Most Powerful Newsletters

    ADS BY GOOGLE

    Coca-Cola’s Google powered digital signage system lays the groundwork for a more valuable connection...
    In his keynote at 18th Cloud Expo, Andrew Keys, Co-Founder of ConsenSys Enterprise, provided an over...
    "As we've gone out into the public cloud we've seen that over time we may have lost a few things - w...
    In his session at 21st Cloud Expo, Michael Burley, a Senior Business Development Executive in IT Ser...
    You know you need the cloud, but you’re hesitant to simply dump everything at Amazon since you know ...
    "Since we launched LinuxONE we learned a lot from our customers. More than anything what they respon...
    Is advanced scheduling in Kubernetes achievable?Yes, however, how do you properly accommodate every ...
    Sanjeev Sharma Joins June 5-7, 2018 @DevOpsSummit at @Cloud Expo New York Faculty. Sanjeev Sharma is...
    The need for greater agility and scalability necessitated the digital transformation in the form of ...
    As DevOps methodologies expand their reach across the enterprise, organizations face the daunting ch...
    While some developers care passionately about how data centers and clouds are architected, for most,...
    DevOps is under attack because developers don’t want to mess with infrastructure. They will happily ...
    We are given a desktop platform with Java 8 or Java 9 installed and seek to find a way to deploy hig...
    "I focus on what we are calling CAST Highlight, which is our SaaS application portfolio analysis too...
    "Cloud4U builds software services that help people build DevOps platforms for cloud-based software a...
    The question before companies today is not whether to become intelligent, it’s a question of how and...
    Kubernetes is an open source system for automating deployment, scaling, and management of containeri...
    DevOps is often described as a combination of technology and culture. Without both, DevOps isn't com...
    As many know, the first generation of Cloud Management Platform (CMP) solutions were designed for ma...
    DevOps is often described as a combination of technology and culture. Without both, DevOps isn't com...