Antipattern ideas are not new

Should developers spend more time on the study of antipatterns or design pat-terns? I will answer this with another true adventure story. Throughout the better part of this past century, mountain climbers across the world had an ulti-mate goal: to scale Mt. Everest, the highest summit in the world. Over time, mountaineers tried many different approaches that would allow political pas-sage to the mountain, solid expedition logistics, and the best chances for suc-cess. Two routes go through Tibet. George Mallor y was an early British mountain climber, famous for saying he climbed Everest “Because it is there.”

He made his attempts on the north face, over terrain called the North Col.

The other northern route was considered much too dangerous for early moun-taineers. Edmund Hillary, who became the first to climb Everest, eventually

14 ^{CHAPTER 1} Bitter tales

succeeded on the southern face, through Nepal. That route is called the South Col route. After the first ascent, expeditions climbed this dangerous mountain with greater regularity and greater margins of safety. They began to unlock the secrets of operating at high altitude and to find where the inevitable danger spots were likely to be. They began to understand when the summer monsoons directed the jet stream away from Everest to provide a window of acceptable weather. They learned to leave their tents at midnight so that they would not be trapped on the summit in the afternoon, when the weather frequently dete-riorated. They were using design patterns.

Inevitably, people started to guide trips up the mountain with increasing success. Many debated that some of the paid clients did not have the appropri-ate skills to be on the mountain and would not be able to handle themselves in the event of an emergency. These criticisms turned out to be prophetic. Two expeditions led by the strongest guides in the world got trapped at the top of Everest through a series of poor decisions and bad luck. An afternoon storm killed many of them, including three of the six guides and several of the cli-ents. Jon Krakauer made this incident famous in the book Into Thin Air. The design patterns were able to get them to the top but were unable to get them safely back down. Good application of climbing antipatterns, like avoiding the top of the mountain at dangerous times and holding fast to a prescribed turn-around time, could have made the difference.

1.4.1 Learning from the industry

In many real-world situations, the principles of design patterns and antipat-terns are combined. In heath care, aggressive preventive care (design patantipat-terns) is combined with systematic diagnostics of health-related issues (antipatterns).

In manufacturing, quality certification programs like ISO 9000 (design pat-terns) are combined with aggressive process analysis, problem identification, and continuous improvement (antipatterns). Road signs are combined to point out good driving behaviors like “Pass on left” and hazards like “Watch for fall-ing rock.” In many other fields, the two practices go hand in hand. Software engineers should try to combine these two approaches.

A powerful movement in the quality industry, from the late ’70s through the ’80s, sought to involve front-line assembly workers in the quality process.

These teams were tightly integrated with quality professionals. The teams, sometimes with light-handed management direction, would identify problems and contribute a block of time weekly toward solutions to those problems. My father, Robert G. Tate, Jr., became so attached to this process that he left a high-level position at Dover Elevators to pursue a consulting career installing

Antipattern ideas are not new 15

“quality circles” around the world. He found that something magical hap-pened with the involvement of the actual blue-collar plant floor. The relation-ships changed. Management, quality control, and the product builders began to work together. The process was remarkably simple:

■ Quality circles would form for the purpose of solving quality problems.

■ Participants would become involved in the identification and solution of quality problems.

■ Management would empower them to deal with quality problems directly.

■ Participants were educated to perform these tasks.

Many of the quality groups showed staggering returns. Other programs, such as Zero Defects, also thrived. Awards and accreditations, like Malcolm Bald-rige and ISO 9000, gathered steam. The United States again discovered the value of quality.

In a very real sense, this book represents the same ideas that we see in other areas and places them in the context of Java application development.

We are taking responsibility for bringing quality code to the desk of the com-mon programmer. We want to identify places where our assembly line is bro-ken. We want to spot holes in process and procedure that can cripple our customers or even ourselves down the road. We want to know when major sys-tematic problems, like the routinely late turnaround times on Everest, occur.

We then want to systematically solve them and save others from repeating our mistakes. Most of this book deals with antipatterns that are already well entrenched in Java programs, processes, and programmers. We should now talk briefly about the discovery process.

1.4.2 Detective work

Experienced, conscientious programmers find most antipatterns. While teaching the instincts of a detective may be difficult, I can provide some rules of thumb from my consulting experience. These tips represent the places and methods that I use to find antipatterns hiding in a customer’s process, or my own.

Bug databases contain a bounty of wealth

Most organizations already track quality metrics in the form of bug databases.

We can look to establish patterns based on keyword searches and spot checks.

Are we seeing a pattern of memory leaks? If so, misconceptions or frameworks could be a source of bad behavior. Are the change lists for view-related main-tenance particularly long? If so, this could point to tight coupling. Are certain

16 ^{CHAPTER 1} Bitter tales

objects or methods particularly vulnerable to bugs? If so, they might be refac-toring targets.

Early performance checks can point out design flaws

Sanity checks for performance early in a process can point to design flaws.

Some of these might be isolated incidents. Some, even at an early stage, are likely to be common enough to warrant special attention. Internet applications are particularly vulnerable to communication overhead. Several of the antipat-terns in this book deal with round-tripping, or making many communications do a relatively isolated task. Sloppy programming, including many of the issues in chapter 9, can also cause performance problems, especially in tight loops.

Frequent code inspections and mentors help

Beginners and early intermediates can be a common source of antipatterns.

Pairing them with more experienced programmers and architects for code reviews and mentoring can head off many bad practices before they start. At allmystuff, the engineering department did a nice job of mentoring the solu-tions development staff, which typically consisted of weaker developers with better customer skills. Even a five-minute code inspection can reveal a surpris-ing amount of information. Are the methods too long? Is the style readable and coherent? Are the variable names appropriately used? Does the program-mer value her intelligence above readability?

End users are unusually perceptive

Later in my career, I began to appreciate the impact of end-user involvement at all stages of development. I found that end users can be brutally honest, when we allow them to be. When I began to truly listen to feedback, I could tell very early if my team would need to bear down or change direction. Too often, we ask for the questions and listen only if we hear what we want or expect.

Outsiders can use interviews

The most powerful tool for someone outside a development organization is the interview. People are put off when we try to propose answers without ask-ing questions. Gettask-ing them to open up in an interview is usually not difficult but may occasionally be troublesome. When we are digging for trouble, peo-ple are much more perceptive if they perceive that we are helping to solve problems and not looking for someone to blame. Interviews are most useful if we can script at least a set of high-level questions, as well as anticipate some low-level questions.

Why Bitter Java? 17

Establishing a pattern

By itself, a problem is only a bug. We should already have processes and proce-dures for identifying and fixing bugs. Indeed, many of my father’s customers had adequate measures for detecting and removing bad products from the line. The problems with these reactive approaches are twofold. First, we will never find all of the bugs. Second, if we do not fix the machinery or the pro-cess, we will create more bugs! After we have established a pattern, we need to elevate it from bug to antipattern.

1.4.3 Refactoring antipatterns

After we find a problem and establish a pattern, our strategy calls for refactor-ing it to form a better solution and process. Here, we are overlapprefactor-ing the realms of design patterns and antipattern. My intuition is that this tion is part of what is missing in the software quality industry. The combina-tion of design patterns and antipatterns is practical and powerful. Poor solutions can be identified through antipatterns and redesigned into more proven and practical alternatives using design patterns. The process of contin-ually improving code through restructuring for clarity or flexibility and the elimination of redundant or unused code is called refactoring.

Many experts advocate the rule “If it isn’t broke, don’t fix it.” In the realm of software development, following this rule can be very expensive, especially at the beginning of a program’s life cycle. The average line of code will be changed, modified, converted, and read many times over its lifetime. It is folly to view a refactoring exercise as time wasted without considering the tremen-dous savings over time. Instead, refactoring should be viewed as an investment that will pay whenever code is maintained, converted, read, enhanced, or oth-erwise modified. Therefore, refactoring is a cornerstone of this book.