AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis / Edition 1

Paperback (Print)
Used and New from Other Sellers
Used and New from Other Sellers
from $6.39
Usually ships in 1-2 business days
(Save 89%)
Other sellers (Paperback)
  • All (17) from $6.39   
  • New (8) from $35.32   
  • Used (9) from $6.39   


"The AntiPatterns authors have clearly been there and done that when it comes to managing software development efforts. I resonated with one insight after another, having witnessed too many wayward projects myself. The experience in this book is palpable." -John Vlissides, IBM Research "This book allows managers, architects, and developers to learn from the painful mistakes of others. The high-level AntiPatterns on software architecture are a particularly valuable contribution to software engineering. Highly recommended!" -Kyle Brown Author of The Design Patterns Smalltalk Companion "AntiPatterns continues the trend started in Design Patterns. The authors have discovered and named common problem situations resulting from poor management or architecture control, mistakes which most experienced practitioners will recognize. Should you find yourself with one of the AntiPatterns, they even provide some clues on how to get yourself out of the situation." -Gerard Meszaros, Chief Architect, Object Systems Group Are you headed into the software development mine field? Follow someone if you can, but if you're on your own-better get the map! AntiPatterns is the map. This book helps you navigate through today's dangerous software development projects. Just look at the statistics:
* Nearly one-third of all software projects are cancelled.
* Two-thirds of all software projects encounter cost overruns in excess of 200%.
* Over 80% of all software projects are deemed failures.
While patterns help you to identify and implement procedures, designs, and codes that work, AntiPatterns do the exact opposite; they let you zero-in on the development detonators, architectural tripwires, and personality booby traps that can spell doom for your project. Written by an all-star team of object-oriented systems developers, AntiPatterns identifies 40 of the most common AntiPatterns in the areas of software development, architecture, and project management. The authors then show you how to detect and defuse AntiPatterns as well as supply refactored solutions for each AntiPattern presented.

Want to avoid "Projects from Hell" and software runaways? Then, study AntiPatterns. AntiPatterns are the opposite of Patterns, which are procedures and policies that complete software projects on time and within budget. AntiPatterns are commonly occurring solutions that generate decidedly negative consequences.

Read More Show Less

Editorial Reviews

As the knowledge of what to avoid in programming is crucial to software success, the authors introduce 40 common programming solution methods that have unforeseen and incorrect effects on software. The volume covers common design "AntiPatterns" in software development, architecture, and managerial stages, and explains more successful ways to get around problems. Annotation c. by Book News, Inc., Portland, Or.
Read More Show Less

Product Details

  • ISBN-13: 9780471197133
  • Publisher: Wiley
  • Publication date: 4/3/1998
  • Edition number: 1
  • Pages: 336
  • Product dimensions: 9.25 (w) x 7.50 (h) x 0.70 (d)

Meet the Author

WILLIAM J. BROWN is an independent consultant with extensive experience in large-scale software development project management. RAPHAEL C. MALVEAU is Chief Scientist at Eidea Labs and specializes in building CORBA applications using design patterns. HAYSW. "SKIP" McCORMICK III is a lead engineer at Mitre Corporation, focusing on object-oriented systems development and legacy systems integration. THOMAS J. MOWBRAY is the architect of one of the first CORBA-based applications systems. He is the Principal Scientist at Blueprint Technologies Corporation and an architecture columnist for Object Magazine.

Read More Show Less

Read an Excerpt

Chapter 2: Antipatterns Reference Model

Primal Forces

Software design involves making choices. For example, some of the key choices that present themselves when designing software architecture include:
  • Which details to expose and which details to abstract.
  • Which features to include and which features to exclude.
  • Which aspects to make flexible and extensible.
  • Which aspects to constrain and guarantee.

Software design choices are often complex, with numerous issues (or forces) to consider, such as security, cost, adaptability, reliability, and so on. In order to make good choices, it's very important to clarify the context of the decision. Choices are clarified in several ways, such as:

  • Separation of concerns.
  • Establishing priorities.

To separate concerns, we need to limit the scope of each choice. Partitions in a software architecture are used to allocate and delineate the boundaries of concerns. Each partition is responsible for resolving a limited set of issues, which simplify decision making. The architecture represents the union of the partitions and provides coverage of all the relevant issues. This separation of concerns is a fundamental role of architecture.

Decisions are also clarified by an understanding of priorities. If we know what is important and what is not, it's much easier to choose what to include and what to exclude in a design. Decisions are difficult because they include some items and exclude many others, and we must be able to justify such choices. This is another fundamental role of architecture, to explain significant decisions and design choices.

Risk is a force that is always present in software decisions. Software projects are amazingly prone to failure. As noted, approximately one-third of all software projects are canceled, and approximately only one-sixth of software projects are considered successful. The remaining projects are typically over-budget and over-schedule by factors of two or more. The unsuccessful projects are also incapable of delivering the desired features. Once the systems are delivered, there is high risk involved in changing the system. Correction or extensions are likely to cause new software problems.

Considering these statistics, five out of six software projects are destined to fail. These figures are essentially unchanged by new technologies and approaches such as client/server and object orientation. As software professionals, the outlook is grim, unless something significant changes. We believe that significant changes are necessary in the way that software systems are architected and the way that risks are managed.

We see risk as a generalized force, which is an underlying factor in most other forces. To various degrees, management of risk is a universal force that motivates the patterns and solutions described here.

What Is a Primal Force?

Forces are concerns or issues that exist within a decision-making context. In a design solution, forces that are successfully addressed (or resolved) lead to benefits, and forces that are unresolved lead to consequences. For any given software problem, there are a number of forces that can influence a given solution. The application of a design pattern leads to a solution that resolves the forces in a particular way. In the solution, some forces are resolved more completely than others. The choice of a design solution establishes a priority on the forces, to the extent that the highestpriority forces are resolved the most completely.

Some forces are domain-specific. Domain-specific forces (called vertical forces) are unique to a particular situation due to the domain or problem addressed. Since vertical forces are unique (or local) to one software situation, resolution of vertical forces usually results in unique solutions for each software problem.

Another class of forces, horizontal forces, are applicable across multiple domains or problems. Horizontal forces are those that influence design choices across several software modules or components. With horizontal forces, design choices made elsewhere may have a direct or indirect impact on design choices made locally. For example, if the horizontal force is "design consistency," it is necessary to coordinate software designs across multiple software modules to ensure such consistency.

A certain class of horizontal forces are pervasive in software architecture and development. These are the primal forces, and are present in nearly all design situations, and should be considered part of the contextual forces driving most solutions. One role of the primal forces is to keep architecture and development on track. For example, a software decision that seems to be local can have a cumulative impact when there are other software groups making conflicting choices elsewhere in the same enterprise. The primal forces represent the pervasive forces, which arise from the interrelatedness of software decisions.

The primal forces are an important part of the guidelines presented in this pattern language. Each primal force is horizontally applicable across many domains of software architecture and development. The primal forces represent the common-sense basic considerations, which are necessary for successful software architecture and development. Primal forces comprise a fundamental value system for software architects and developers that are independent of particular situational forces.

The primal forces include:

  • Management of functionality: meeting the requirements.
  • Management of performance: meeting required speed of operation.
  • Management of complexity: defining abstractions.
  • Management of change: controlling evolution of software.
  • Management of IT resources: controlling use and implementation of people and IT artifacts.
  • Management of technology transfer: controlling technology change.

The primal forces have different relative importance at different scales. Functionality and performance are critical forces at applicationlevel and finer grains, whereas management of IT resources and technology transfer are enterprise and global in scope. Before we can discuss these fully, we need to define the scales through the scalability model.

Table 2.1 identifies the degrees of impact of forces at the different levels of scale:

Critical. The impact is fundamental, as it affects all of the software.

Important. The impact must be seriously considered, as it affects a significant amount of the software.

Marginal. The impact can often be ignored, as it affects a minimal portion of the software.

Unimportant. The impact should not be considered....

Read More Show Less

Table of Contents


Introduction to Patterns and AntiPatterns.

AntiPatterns Reference Model.

Templates for Patterns and AntiPatterns.

Advice for Using AntiPatterns.

ANTIPATTERNS Software Development AntiPatterns.

Software Architecture AntiPatterns.

Software Project Management AntiPatterns.




Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star


4 Star


3 Star


2 Star


1 Star


Your Rating:

Your Name: Create a Pen Name or

Barnes & Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation


  • - By submitting a review, you grant to Barnes & and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Terms of Use.
  • - Barnes & reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously
Sort by: Showing all of 2 Customer Reviews
  • Anonymous

    Posted December 30, 1999

    Easy read and possibly worthwhile if you are in to stuff like this

    If you haven't read 'Design Patterns' (commonly known as the Gamma or GoF book,) read or skim it first. If you think patterns are the coolest thing since sliced bread, read this book skeptically. I think it has a lot of interesting points to make but suffers from inconsistency, perplexing forced humor, and unnecessary formalisms. However, it is an easy read and possibly worthwhile if you are in to stuff like this. I think the authors added too much formality to what should be a somewhat straightforward ideas. Ironically, a claimed goal of their style was to make these more interesting to read than the GoF style patterns. I think this and other problems with this book are rooted in that they wanted to make this a seminal work. I felt that they were overly confident in their solutions. I also think that their solutions were often on the simplistic side. There was a lot of unacknowledged hand waving. Because this is an 'anti-' book, it feels like they say 'you shouldn't not do this' instead of just saying 'you should do this'. Sometimes it was hard to tell if a bulleted list was talking about bad results of a particular pattern or the good things that happen when you follow their advice. There were four authors and I think the result was a lack of consistency. The book starts off saying that no design methodology is a silver bullet (including object orientation). However, almost all of their antipatterns and their refactored solutions are object oriented. I think they tried too hard to be colorful in the names of their antipatterns. For example, rather than using a common

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted October 31, 2008

    No text was provided for this review.

Sort by: Showing all of 2 Customer Reviews

If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)