Adopting Xp Pattern Language Discussion
Adopting Xp Pattern Language DiscussionFrom AdoptingXpPatternLanguage.
I humbly suggest, though, that you delete this and the other "mechanically named" pages from AdoptingXpPatternLanguage. They are not patterns - a pattern is something you've used and which worked. My own suggestions probably aren't much better as patterns - to really qualify for a pattern you need something that worked more than once; three times is canonical. They might do for a starting point, being derived from actual experience. -- LaurentBossavit
I disagree, but let me explain why. I am not qualified to write these patterns, that is true. But that doesn't mean they don't exist. People have succeeded in AdoptingXp, there are patterns to this, and I would like to know what they are. This is a PromptingStatement 100%, and it was intended that way. If anyone thinks I don't know what I'm talking about when it comes to AdoptingXp, they're right! Correct me. Fill in the blanks. This is one of the areas that the documentation on XP is lacking, and if we can develop an AdoptingXpPatternLanguage, it would be a big factor in SellingXp.
Thoughts? Comments? Does anyone agree or disagree that this would be a valuable set of documents for helping groups interested in TransitioningToExtremeProgramming? -- RobHarwood
I should learn to express myself more clearly. I entirely welcome your initiative, filling as it does a gap that I myself felt keenly when in the early days of getting my mind around XP. Compared to my own effort - what I attempted was a narrative form, which turns out not to work - your idea of seeding the initial patterns of a PatternLanguage probably holds much more promise.
Neither veterans nor beginners, I believe, are more qualified to contribute to a pattern language that specifically adresses the transition to XP. As beginners, we have the advantage of an experience that is fresh in our minds. The veterans - on days which find them in full possession of their eroding but still formidable mental capacities - will probably be able to write down a fond memory or two from those long-ago years. ;)
What I'm not particularly drawn to, specifically, is the "synthetic" approach to patterns. Not that I claim to be any authority on PatternLanguages; I just observe that nothing which is currently presented as a PatternLanguage has a form as regular as the first set of proposed patterns above. I submit that as patterns, they are not directly useful and are unlikely to survive.
If you agree with that sentiment, and PairNonBelieversWithBelievers has me thinking that might be the case, then let's junk them; YouArentGonnaNeedIt applies. If you still disagree, it's no more my Wiki than it is yours; consensus will emerge, somehow.
I'm beginning to understand your point of view. When I originally came up with the admittedly boring names, I was thinking to myself, "I wish someone had written a nice succinct page on 'How To Adopt Pair Programming', etc., one practice at a time." This sounded like a good candidate for the PatternForm, and since PatternNames? are usually imperative, I figured that AdoptPairProgramming would be a good name. The idea being that you could use it in a Wiki conversation like this:
An interesting observation in the above : you went from the question "how do I get started with practice X" to a different one, "how would I help others get started with practice X". This suggests two potential approaches - one for people wanting, of their own initiative, to install XP practices in their team; and one for people who, finding XP already installed, or recognizing XP practices as potentially useful, may need help figuring out what they need to learn.
I classify myself firmly in the first category, and believe this burgeoning pattern language will be useful mainly people with in that category. My preference for pattern names stems from this opinion.
I would refer people in the second category to the very useful page ExtremeProgrammingCorePractices.
A pattern doesn't teach you how to do a specific thing; it tells you which solution, from those you already know about, applies to what class of problems. So people in need of a new solution will benefit more from a description of the solution than from a pattern.
So, if I may paraphrase, the two categories are:
I'm not sure I agree with your assessment of patterns. In GoF's DesignPatterns, each pattern "systematically names, explains, and evaluates" an important and recurring solution. I would like the AdoptingXpPatternLanguage to have a similar feel to it. Perhaps, as you say, AdoptUnitTests doesn't ring like a regular pattern name. Perhaps it could be something else. But when your problem is low code quality, and your organization is resisting change, the solution is to AdoptUnitTests. And hopefully, there's a repeatable pattern involved there somewhere. Hmm... Maybe the problem is adopting unit testing, and the solutions are patterns like LetTheTestsSpeakForThemselves. <grumble> I'm confused. :-) -- RH
You're not. You're there. The problem is bad code quality in your team, the issue is getting unit tests adopted, and LetTheTestsSpeakForThemselves will hopefully describe a way to go about achieving that.
Just to play DevilsAdvocate for a second, perhaps there are two problems.
Still confused ?
No, I think I'm happy with the two-problems view of it. There are reasons to adopt the various practices and general techniques to go about doing so, and these are suited to being written up as patterns. Likewise, the various techniques themselves are suited to being written as their own patterns.
The AdoptWhatever patterns are useful (I think) because they give a context to the individual XP practices that you want to adopt. E.g. You pretty much need to adopt unit tests before you can adopt refactoring, so a good place to put that information would be in the AdoptRefactoring page.
EditText of this page
(last edited January 10, 2005)
or FindPage with title or text search