Design patterns is one of the popular term in software engineer. In architecture works, it is used as the common words for discussing also applying the practices to designer daily work. However, when designer apply some pattern for some problem, they usually forgot the three most important things in one pattern, they are:

• Intent: describe the goal of pattern and reason to use it.
• Motivation: provides the scenario consisting of a problem and providing the context that pattern can solve.
• Consequences: the side effects cause by this pattern.

Mostly, this problem is applied for both novice designer who is dizzy with what pattern does also 'experienced' designer who apply patterns base on their previous projects. I can say some common practices:

1. If client request support multiple databases --> DAO pattern. If they don't why do we need apply that.
2. For one instance has global scope --> use singleton pattern. See this for some comments on singleton pattern.
3. Undo/redo use command pattern.
4. Validation or pre-processing use Chain of responsibility pattern
5. etc

Some is correct for almost contexts of problem but it is not true for whole cases. For example, if you know what the system only support one database, do you need to apply DAO pattern. I see one case when designer can not answer the questions from client that why they apply DAO pattern in case only one database is served for system. It is because he did not know the motivation of DAO pattern (what the bad of some stupid books J2EE design pattern when it describe DAO because it hides the main idea of Factory pattern in GoF and makes people think the main purpose of DAO pattern is served to multiple databases).

I have read this jokes about applying wrong pattern and it is actually true, you should think that applying pattern is not the ideal solution except use it correctly. If you can not, it can cause harm to you work. Note that the original article is gotten from http://www.lsd.ic.unicamp.br/~oliva/fun/prog/resign-patterns but I would like to copy here in case this link is invalid in future (I have some bad practices when I add some favorite link but later I loss such knowledge in case these links are not longer existed).

Resign Patterns
Ailments of Unsuitable Project-Disoriented Software
by
Michael Duell
mitework@yercompany.com

Abstract

Anyone familiar with the book of patterns by the Gang of Four [1]
knows that the patterns presented in the book represent elegant
solutions that have evolved over time. Unfortunately, extracting these
patterns from legacy code is impossible, because nobody knew that they
were supposed to be using these patterns when they wrote the legacy
code. Hence, this work is a catalog of patterns for the masses. The
patterns presented here represent abundant solutions that have endured
over time. Enjoy reading the patterns, but please don't use them!

1 Cremational Patterns

Below is a list of five cremational patterns.

1.1 Abject Poverty

The Abject Poverty Pattern is evident in software that is so difficult
to test and maintain that doing so results in massive budget overruns.

1.2 Blinder

The Blinder Pattern is an expedient solution to a problem without
regard for future changes in requirements. It is unclear as to whether
the Blinder is named for the blinders worn by the software designer
during the coding phase, or the desire to gouge his eyes out during
the maintenance phase.

1.3 Fallacy Method

The Fallacy method is evident in handling corner cases. The logic
looks correct, but if anyone actually bothers to test it, or if a
corner case occurs, the Fallacy of the logic will become known.

1.4 ProtoTry

The ProtoTry Pattern is a quick and dirty attempt to develop a working
model of software. The original intent is to rewrite the ProtoTry,
using lessons learned, but schedules never permit. The ProtoTry is
also known as legacy code.

1.5 Simpleton

The Simpleton Pattern is an extremely complex pattern used for the
most trivial of tasks. The Simpleton is an accurate indicator of the
skill level of its creator.

2 Destructural Patterns

Below is a list of seven destructural patterns.

2.1 Adopter

The Adopter Pattern provides a home for orphaned functions. The result
is a large family of functions that don't look anything alike, whose
only relation to one another is through the Adopter.

2.2 Brig

The Brig Pattern is a container class for bad software. Also known as
module.

2.3 Compromise

The Compromise Pattern is used to balance the forces of schedule vs.
quality. The result is software of inferior quality that is still
late.

2.4 Detonator

The Detonator is extremely common, but often undetected. A common
example is the calculations based on a 2 digit year field. This bomb
is out there, and waiting to explode!

2.5 Fromage

The Fromage Pattern is often full of holes. Fromage consists of cheesy
little software tricks that make portability impossible. The older
this pattern gets, the riper it smells.

2.6 Flypaper

The Flypaper Pattern is written by one designer and maintained by
another. The designer maintaining the Flypaper Pattern finds herself
stuck, and will likely perish before getting loose.

2.7 ePoxy

The ePoxy Pattern is evident in tightly coupled software modules. As
coupling between modules increases, there appears to be an epoxy bond
between them.

3 Misbehavioral Patterns

Below is a list of eleven misbehavioral patterns.

3.1 Chain of Possibilities

The Chain of Possibilities Pattern is evident in big, poorly
documented modules. Nobody is sure of the full extent of its
functionality, but the possibilities seem endless. Also known as
Non-Deterministic.

3.2 Commando

The Commando Pattern is used to get in and out quick, and get the job
done. This pattern can break any encapsulation to accomplish its
mission. It takes no prisoners.

3.3 Intersperser

The Intersperser Pattern scatters pieces of functionality throughout a
system, making a function impossible to test, modify, or understand.

3.4 Instigator

The Instigator Pattern is seemingly benign, but wreaks havoc on other
parts of the software system.

3.5 Momentum

The Momentum Pattern grows exponentially, increasing size, memory
requirements, complexity, and processing time.

3.6 Medicator

The Medicator Pattern is a real time hog that makes the rest of the
system appear to be medicated with strong sedatives.

3.7 Absolver

The Absolver Pattern is evident in problem ridden code developed by
former employees. So many historical problems have been traced to this
software that current employees can absolve their software of blame by
claiming that the absolver is responsible for any problem
reported. Also known as It's-not-in-my-code.

3.8 Stake

The Stake Pattern is evident in problem ridden software written by
designers who have since chosen the management ladder. Although
fraught with problems, the manager's stake in this software is too
high to allow anyone to rewrite it, as it represents the pinnacle of
the manager's technical achievement.

3.9 Eulogy

The Eulogy Pattern is eventually used on all projects employing the
other 22 Resign Patterns. Also known as Post Mortem.

3.10 Tempest Method

The Tempest Method is used in the last few days before software
delivery. The Tempest Method is characterized by lack of comments, and
introduction of several Detonator Patterns.

3.11 Visitor From Hell

The Visitor From Hell Pattern is coincident with the absence of run
time bounds checking on arrays. Inevitably, at least one control loop
per system will have a Visitor From Hell Pattern that will overwrite
critical data.

4 References

Gamma, E., Helm, R., Johnson, R., Vlissides, J., Design Patterns -
Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995.