AntiPatterns
Refactoring Software, Architectures, and Projects in Crisis
William J. Brown
Raphael C. Malveau
Hays W. McCormick III
Thomas J. Mowbray
John Wiley & Sons, Inc.
Publisher: Robert Ipsen
Editor: Theresa Hudson
Managing Editor: Micheline Frederick
Text Design & Composition: North Market Street Graphics
Copyright © 1998 by William J. Brown, Raphael C. Malveau, Hays W. McCormick III, and
Thomas J. Mowbray. All rights reserved.
Published by John Wiley & Sons, Inc.
Published simultaneously in Canada.
No part of this publication may be reproduced, stored in a retrieval system or transmitted in
any form or by any means, electronic, mechanical, photocopying, recording, scanning or
otherwise, except as permitted under Sections 107 or 108 of the 1976 United States
Copyright Act, without either the prior written permission of the Publisher, or authorization
through payment of the appropriate per−copy fee to the Copyright Clearance Center, 222
Rosewood Drive, Danvers, MA 01923, (978) 750−8400, fax (978) 750−. Requests to the
Publisher for permission should be addressed to the Permissions Department, John Wiley &
Sons, Inc., 605 Third Avenue, New York, NY 10158−, (212) 850−, fax (212) 850−, E−Mail:
PERMREQ @ WILEY.COM.
This publication is designed to provide accurate and authoritative information in regard to the
subject matter covered. It is sold with the understanding that the publisher is not engaged in
professional services. If professional advice or other expert assistance is required, the
services of a competent professional person should be sought.
Designations used by companies to distinguish their products are often claimed as
trademarks. In all instances where John Wiley & Sons, Inc., is aware of a claim, the product
names appear in initial capital or all capital letters. Readers, however, should contact the
appropriate companies for more complete information regarding trademarks and registration.
ISBN_0−471−19713−0 (cloth : alk. paper)
This book is dedicated to our families:
Kate Brown,
Carrie Malveau,
Kim McCormick,
and
Kate Mowbray, CPA
“And ye shall know the truth and the truth shall set you free”
—John 8:32
Executive Summary
Overview
1
This book will help you identify and overcome prevalent, recurring roadblocks to successful
software development. AntiPatterns clearly define software mistakes that most of us make
frequently. In fact, most of us could achieve ISO 9001 with our consistency! AntiPatterns also
provide solutions: How to fix existing problems and how to avoid repeated mishaps in the
future. In short, AntiPatterns describe and solve real−world problems. The following
questions are a sample of what AntiPatterns have to offer:
1. What are the two most common software design mistakes? How can I recognize them?
See the AntiPatterns the Blob and Poltergeists in Chapter 5.
2. What can we do to fix (or refactor) bad software? See the AntiPatterns Spaghetti Code in
Chapter 5, and Stovepipe Systems in Chapter 6.
3. Our design project is going around in circles; how can we get it back on track? See the
AntiPatterns Analysis Paralysis in Chapter 7 and Design by Committee in Chapter 6.
4. How do I know when I’m being misled by a software vendor? See the AntiPatterns
Vendor Lock−in in Chapter 6, and Smoke and Mirrors in Chapter 7.
5. Is the latest standard or technology breakthrough going to solve my problems? See the
AntiPatterns Wolf Ticket in Chapter 6 and Continuous Obsolescence in Chapter 5.
6. Is our software project headed for disaster? See the AntiPatterns Death by Planning in
Chapter 7, and Mushroom Management in Chapter 5.
7. What are the “gotchas” of software reuse? See the AntiPatterns Cut−and−Paste
Programming and Golden Hammer in Chapter 5.
AntiPatterns clarify the negative patterns that cause development roadblocks, and include
proven solutions for transforming software development problems into opportunities.
AntiPatterns serve two important purposes: to help identify problems and to help implement
solutions. Understanding the problem is the first step to recovery. Solutions are of little use
without a state problem to solve. AntiPatterns have a variety of causes, with associated
symptoms and consequences. We convey these aspects of each AntiPattern to clarify the
motivation for change. We then offer proven, recurring solutions for the AntiPattern.
AntiPatterns are closely related to another important software concept: design patterns,
which document recurring solutions. A design pattern becomes an AntiPattern when it
causes more problems than it solves.
Figure E.1 Build your own nightmare.
All patterns have consequences. There are situations when a pattern is a good solution to a
problem and other situations when it becomes an AntiPattern. The context−dependent
consequences are important to understand in order to make an informed decision inclusive of
side effects. We examine this viewpoint for each pattern and describe when an AntiPattern
can actually provide benefit:
• Managerial (managing processes and people)
• Architectural (defining a technical strategy)
• Developmental (coding practices)
Managerial, architectural, and developmental AntiPatterns are defined in Chapters 5 through
7. If you are new to design patterns or AntiPatterns, we provide introductory material in
2
Chapters 1 through 3. For design patterns practitioners, the AntiPatterns reference model is
explained in Chapter 2; the template is explained in Chapter 3. These introductory chapters
are instrumental for getting the most out the AntiPattern descriptions.
Table of Contents
AntiPatterns
Foreword
Executive Summary
Part I Introduction to AntiPatterns
Chapter 1 − Introduction to Patterns and AntiPatterns
Chapter 2 − AntiPatterns Reference Model
Chapter 3 − Templates for Patterns and AntiPatterns
Chapter 4 − Advice for Using AntiPatterns
Part II AntiPatterns
Chapter 5 − Software Development AntiPatterns
Chapter 6 − Software Architecture AntiPatterns
Chapter 7 − Software Project Management AntiPatterns
Part III Conclusions and Resources
Appendix A − AntiPatterns Synopsis
Appendix B − AntiPatterns Terminology
Appendix C − Acronyms Used in AntiPatterns
Appendix D − Bibliography
Part I: Introduction to AntiPatterns
Chapter List
Chapter 1: Introduction to Patterns and AntiPatterns
Chapter 2: AntiPatterns Reference Model
Chapter 3: Templates for Patterns and AntiPatterns
Chapter 4: Advice for Using AntiPatterns
Chapter 1: Introduction to Patterns and
AntiPatterns
Overview
AntiPatterns represent the latest concept in a series of revolutionary changes in computer
science and software engineering thinking. As the software field approaches the 50−year
mark of developing programmable, digital systems, we have yet to resolve some
fundamental problems that arise when humans translate business concepts into software
applications. Many of the most significant problems are generated from the human processes
that require shared vision, cooperation, and collaboration to realize systems. The majority of
the published works in software sciences have focused on positive, constructive solutions.
This book is different; we start by looking at the negative solutions.
Academic researchers and practitioners have developed thousands of innovative approaches
to building software, from exciting new technologies to progressive processes. Even with all
these great ideas, the likelihood of success for practicing managers and developers is grim.
A survey of hundreds of corporate software development projects indicated that five out of six
3
software projects are considered unsuccessful [Johnson 95], and approximately a third of
software projects are canceled. The remaining projects delivered software at almost double
the expected budget and time to develop as originally planned.
“Fasten your seat−belts, it’s going to be a bumpy night.”
—Joseph L. Mankiewicz
Virtually all systems delivered are stovepipe systems, systems that cannot accommodate
change. Adaptability is perhaps the most important quality of software. More than half of all
software cost is due to changes in requirements or the need for system extensions [Horowitz
93]. Some 30 percent of the development cost is due to changes in requirements during
system construction.
AntiPatterns: AntiHype
Software was supposed to make digital hardware much more flexible. Instead, software
technology has promulgated a series of failed promises. The promise that software would
make hardware flexible was only the first. What went wrong? Within our careers, we have
seen any number of software fads come and go that were successful in a limited way for
specific aspects of software development, but did not deliver the promised “silver bullet” (see
Figure 1.1). Remember some of these major trends?
Figure 1.1 There are many paths to disaster.
• Structured programming was supposed to improve software productivity and remove most
software defects.
• Artificial intelligence was supposed to make computers much more capable.
• Networking technologies were supposed to make all systems and software interoperable.
• Open systems and standards were supposed to make application software portable and
interoperable.
• Parallel processing was supposed to make computers much more powerful and scaleable.
• Object orientation was supposed to solve the problems of software productivity and
adaptability, and make software highly reusable.
• Frameworks were supposed to make software highly reusable and software development
much more productive.
These claims sound like a broken record; every new software fad makes similar promises.
History has not been written on many of today’s software buzzwords, but their claims sound
very similar to what we have heard before. Current examples include:
The Internet
Component software
Distributed objects
4