I humbly suggest, though, that you delete this and the other "mechanically named" pages from Adopting Xp Pattern Language. 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. -- Laurent Bossavit
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 Adopting Xp, there are patterns to this, and I would like to know what they are. This is a Prompting Statement 100%, and it was intended that way. If anyone thinks I don't know what I'm talking about when it comes to Adopting Xp, 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 Adopting Xp Pattern Language, it would be a big factor in Selling Xp.
Thoughts? Comments? Does anyone agree or disagree that this would be a valuable set of documents for helping groups interested in Transitioning To Extreme Programming? -- Rob Harwood
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 Pattern Language 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 Pattern Languages; I just observe that nothing which is currently presented as a Pattern Language 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 Pair Non Believers With Believers has me thinking that might be the case, then let's junk them; You Arent Gonna Need It 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 Pattern Form, and since Pattern Names are usually imperative, I figured that Adopt Pair Programming would be a good name. The idea being that you could use it in a Wiki conversation like this:
Sounds like you're having trouble with code quality. Why don't you Adopt Unit Tests?
Then nobody has to reply "How do I do that?" since the link is right there. What do you think of this line of reasoning? Maybe You Arent Gonna Need It applies, but I need it, so maybe not... Not sure. -- Rob Harwood
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 Extreme Programming Core Practices.
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:
How do I start XP (or a specific XP practice)?
What is XP all about?
Is this correct?
I'm not sure I agree with your assessment of patterns. In GoF's Design Patterns, each pattern "systematically names, explains, and evaluates" an important and recurring solution. I would like the Adopting Xp Pattern Language to have a similar feel to it. Perhaps, as you say, Adopt Unit Tests 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 Adopt Unit Tests. And hopefully, there's a repeatable pattern involved there somewhere. Hmm... Maybe the problem is adopting unit testing, and the solutions are patterns like Let The Tests Speak For Themselves. 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 Let The Tests Speak For Themselves will hopefully describe a way to go about achieving that.
Just to play Devils Advocate for a second, perhaps there are two problems.
Problem #1: Bad code quality. Possible Solution: Adopt unit tests.
Problem #2: How to get unit tests adopted. Possible Solution: Let The Tests Speak For Themselves.
In that case, it would be correct to classify Adopt Unit Tests as a pattern. Or maybe it's a mini-Pattern Language? Still confused. -- RH
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 Adopt Refactoring page.
See original on c2.com 