Xp Vs Anti Patterns
Xp Vs Anti PatternsThis page is formatted horribly, but I can't see why. Can anybody fix it?
Better? First step was to remove the extra line-breaks (they break wiki italics and bold formatting). It could use a bit more WikiFication?, i.e. crosslinking, formatting.
Copied from XpMailingList from Daniel T. on 3/28/2000
It has not been answered, and I would appreciate feedback from some people using XP.
A recent post on comp.object got me thinking about this subject so I started doing some re-reading over the weekend. I would like to start up a discussion about some of the AntiPatterns listed in the AntiPatternsBook by Brown et al., how they affect XP and how problems might be fixed...
For those not in the know. An antipattern is formed when a solution to a perceived problem causes a completely different problem that is even worse.
Quickly perusing the book, I find that XPs practices seem to do a good job of protecting the project from all of the antipatterns in chapter five (which deals with development level issues,) however there are several antipatterns in chapter 6 that need to be watched for, namely... (Chapter 6 deals with Architecture issues.)
ArchitectureByImplication (a system developed without a documented architecture.) As I understand both XP and the antipattern (and I'm not claiming to understand either all that well), XP has several methods to help insure this antipattern doesn't come about. Namely the SystemMetaphor, PlanningGame, StandupMeeting and PairProgramming (BTW I'm beginning to see pair-programming in a different light, maybe more on that later.) However only the system metaphor addresses this antipattern explicitly.
DesignByCommittee (Committee designs are overly complex and lack a common architectural vision.) Again, XP relies on communication to avoid this. That and the fact that a committee isn't needed to change the design, just one pair with a lot of time on their hands. :-)
XP relies on simple design to avoid complex design. XP does design by committee, and might lack a common architectural vision, but they shouldn't be overly complex. -- RalphJohnson
ReinventTheWheel (Legacy systems with overlapping functionality don't interoperate. Every system is built in isolation.) I have strong reservations about this one, especially after KentBeck's comments on a "money" class. Although framework reuse seems to be lauded by XPers (especially the StarUnit framework.)
StovepipeEnterprise? (Uncoordinated software architectures lead to lack of adaptability, reuse, and interoperability.) XP doesn't seem to have any processes to address this antipattern. I feel that XP should take definite measures to address this issue or it could easily be a problem.
StovepipeSystem (Ad hoc integration solutions and absence of abstraction result in brittle, unmaintainable architectures.) XP seems to put forth great effort to ensure that *this* antipattern will *never* exist! :-)
TheGrandOldDukeOfYork (Four out of five developers cannot define good abstractions; this leads to excess complexity.) XP could clearly suffer on this front (and I'm not just saying that because I'm one of those "abstractionists" that the book talks about. Some people are better at coming up with great frameworks and some are better at coming up with great algorithms. It makes sense to have a formal system in XP to recognize this fact and allow "framework gurus" some explicit say in the design of the program... These people would be better off in the cat-bird seat instead of on the keyboard for instance...
No, XP helps this problem a lot. If your team has NOBODY who can abstract then nothing will help. But suppose two out of ten are good at abstracting. Then as those people pair up with various other folks, they will share their abstracting ability. Abstracting is better done from the catbird seat, by the way. It is the ability to choose good names, to see non-obvious ways to extract commonality, and to refactor. In an XP project, where everything is permitted to change, you can use insight even if you have already written the first draft of the code. I think XP solves this problem as well as any other process does. -- RalphJohnson
JumbleAntipattern (Interface designs are an unfactored mixture of horizontal and vertical elements, which necessitates frequent interface changes and an inability to reuse.) Not only does XP not address this antipattern, XP seems to claim that it doesn't exists! Or at least that the "frequent interface changes" that this antipattern involves are cheap enough not to be a real problem...
The chapter seven antipatterns are all "people issues". As such, in most cases I don't feel that any "design method" should or could protect against them. XP however seems as though it would be especially vulnerable to:
I would like to here what people using XP think. What XP practices do you think address the potential problems above? How? Why?
I am not an XP practioner however I am current reading Scott Amblers Agile Modeling. Here are the benefits from a novice point of view:-
EditText of this page
(last edited October 23, 2005)
or FindPage with title or text search