negative consequences, anyone who has followed software engineering closely
knows that a high percentage of software projects fail. The AntiPatterns text
cites that five of six software projects are considered unsuccessful. Java
projects are not immune. Earlier this weekend, I heard about a canceled Java
project using servlets and JSP s at a Fortune 100 company that will be replaced
with a new project using CICS and C++!
Some of the madness in our industry is caused by outright malice. Some
vendors sell software that they know isn't ready or doesn't work. Some man-
agers resist change and sabotage projects. Some coworkers take shortcuts that
they know they will not have to repair. Most of the time, though, it is simple
ignorance, apathy, or laziness that gets in the way. We simply do not take the
time to learn about common antipatterns. Ignorant of software engineering
history or the exponentially increasing cost of fixing a bug as the development
cycle progresses, we might kid ourselves into thinking we'll take a shortcut
now and fix it later.
Some well-known antipatterns
As programmers, we will run across many antipatterns completely unrelated to
Java. For the most part, we will not go into too many of them, but here are a
few examples to whet your appetite:
Cute shortcuts. We've all seen code that optimizes white space. Some
programmers think that the winner is the one who can fit the most on a
line. My question is, “Who is the loser?”
Optimization at the expense of readability. This one is for the crack pro-
grammers who want you to know it. In most cases, readability in gen-
eral is far more important than optimization. For the other cases,
aggressive comments keep things clear.
Cut-and-paste programming. This practice is probably responsible for
spreading more bugs than any other. While it is easy to move working
code with cut and paste, it is difficult to copy the entire context. In
addition, copies of code are rarely tested as strenuously as the originals.
In practice, cut-and-paste programs must be tested more strenuously
than the originals.
Using the wrong algorithm for the job. Just about every programmer has
written a bubble sort and even applied it inappropriately. We can all find a
shell sort if pressed, and if we understand algorithm analysis theory, we
know that a bubble sort is processed in O( n 2 ) time, and a simple shell sort
is processed in O( n log( n )) time, which is much shorter for longer lists.