- Shopping Bag ( 0 items )
"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.
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:
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:
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....
INTRODUCTION TO ANTIPATTERNS.
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.
CONCLUSIONS AND RESOURCES.
Posted December 30, 1999
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 commonWas this review helpful? Yes NoThank you for your feedback. Report this reviewThank you, this review has been flagged.
Posted October 31, 2008
No text was provided for this review.