Extreme Programming And Patterns

The XP literature (albeit tiny) says very very little about patterns. It is as if these authors wanted to forget about the patterns movement. So I wonder, what do folks think is the role of patterns within XP? (and I'm not talking about the 2-3 patterns mentioned in Martin's Refactoring book). -- JoshuaKerievsky

Considering Kent Beck and Ward Cunningham were two of the driving forces behind the patterns movement it seems unlikely the XP authors would want to forget about it. -- MartijnMeijering

Nevertheless, in the XP process at present, patterns are like some very distant cousin. Perhaps this has to do with the evolving understanding of the role of Design in XP (see RefactorOrDesign). Or maybe the authors of XP are just scared that patterns will lead to all sorts of stuff that falls under YouArentGonnaNeedIt. -- JoshuaKerievsky

Patterns are not part of XP, but XPers certainly use patterns. When refactoring code, one needs a direction in which to refactor -- a refactoring goal, so to speak. Patterns are often good refactoring goals. -- RobertCecilMartin 12/16/99, 23:29

So, Robert, let me re-phrase what you are saying: patterns are good refactoring goals and XPers use patterns -- however, patterns aren't part of XP. Are you trying to sound like a Zen Master, Robert, or do you really think these kinds of proclamations will help people and teams?

Yes, I really think this helps. We don't include 'if' statements as a necessary part of XP, we don't include inheritance as a necessary part of XP, and we don't include design patterns as a necessary part of XP. XP and Patterns are orthogonal concepts. You can do XP without patterns, and you can use patterns without XP.

Having said that, I would expect any reasonably experienced XPer to be very conversant with patterns, and to employ them on a regular basis as refactoring targets. -- RobertCecilMartin 1/19/00 07:48

Why don't we simply say that the ideal XP team would be one in which both the Coach and his or her programmers know nothing about patterns. As refactorers, they will simply let the code go where it wants to go (as Ron says below) and their ignorance of patterns will not only not get in the way of their producing simple, effective code (OnceAndOnlyOnce, etc.), but this ignorance will actually help them produce this code. -- JoshuaKerievsky

People often ask me "So do I need to learn Design Patterns to do XP? Or should I just read the Refactoring book?"

Well, considering that the Refactoring book touches on about 2-3 patterns (uh, Strategy and Template Method off the top of my head) what do you think my answer is?

The XP authors are struggling to put into words what they do. I'd argue that what they do involves a fairly good grasp of the patterns literature to date. Their knowledge of patterns steers them in refactoring. So if they don't talk about pattern anymore, how do they expect XP teams to effectively refactor? Is the XP philosophy to ignore time-honored, recurring solutions to problems?

-- JoshuaKerievsky

Somewhere on these pages Ron Jeffries said that you should have the GOF patterns in your bag of tricks, but that you shouldn't reach too deep in it too soon. It is better to refactor a pattern into your design than to start with it. Ralph Johnson said something similar a couple of days ago on a newsgroup. The GOF book says that many patterns are natural endpoints for refactoring. -- MartijnMeijering

To you and me, the patterns are natural endpoints for refactoring. To those who don't know patterns, they aren't. Thus, newbie XPers, who lack knowledge of patterns, will have a hard time refactoring their code, especially since the current literature doesn't encourage them to learn patterns. So let us EmbraceChange and fix this. -- JoshuaKerievsky

For each Pattern, the GOF book presents two things: The skeleton without which you don't have the Pattern, and a bunch of illustrative stuff around the pattern that's a total candidate for YouArentGonnaNeedIt. So the correct procedure is to implement the skeleton (paying attention to things like adding the Pattern role names to class names), and deferring all the extras.

Remember that ways to arrange objects - like Pattern skeletons, the DependencyInversionPrinciple, method forwarding, & switch statement abstraction - are scaffolds to hang functionality on, not the functionality itself. Because YouArentGonnaNeedIt targets only functionality as dead weight that must be supported thru the iterations in which it adds no value, the skeleton of a Pattern is a Good Thing so long as it supports even a single crumb of functionality that you need right now. -- PhlIp

Two things:

1. Many programmers with patterns are small children with hammers. You can always tell when someone has just read GOF - they come in the next day wanting to put Composite somewhere.

B. As Josh says, patterns are goals. They are somewhere the human wants to take the code. Refactoring is more like the human taking the code where it wants to go.

In learning XP, many goals are frankly in the way. One is trying to strip oneself of preconceptions and get down to a quiet place where the truth of the code can be heard.

That said, patterns are a wonderful way to know a thing to do when, for a moment, one doesn't know what to do. They're a good tool to have, but a dangerous tool to want to use. Is this paradoxical? Then so be it. -- RonJeffries

Two responses, Ron:

1. Many programmers who get excited about XP, are like small children with hammers. You can always tell when programmers get excited about XP, because they start doing a few practices, like PairProgramming and Testing, and neglect to do the hard stuff, like getting the users fully involved in the XP process. You and I both saw a team do this a few years ago, remember?

Could it be that programmers who get excited about XP put the practices in where they can? Sad to say but I have been on projects where programmers never met with the customer ( military projects ).

B. Patterns are presentations of problems, consequences of problems, solutions to problems, variations on those solutions, and pointers to other patterns. The key to using patterns effectively, is knowing which problems they solve. If you know that, you'll know when to refactor them into code. If you don't, many of your refactorings will fail to improve your code.

Telling experienced folks to let the code go where it wants to go is wonderful. Telling that to inexperienced folks will leave them scratching their heads, wondering what to do next. -- JoshuaKerievsky

The motorcycle ... is almost impossible to understand unless you already know how one works. -- RobertPirsig, ZenAndTheArtOfMotorcycleMaintenance

Josh asks, Why don't we simply say that the ideal XP team would be one in which both the Coach and his or her programmers know nothing about patterns. As refactorers, they will simply let the code go where it wants to go (as Ron says below) and their ignorance of patterns will not only not get in the way of their producing simple, effective code (OnceAndOnlyOnce, etc.), but this ignorance will actually help them produce this code.

I don't say that because I don't believe it.

(It's my practice to say only what I believe, usually. But recall my motto "How do I know what I think until I hear what I say?")

(Cute, Ron. Reminds me of TheHuntingOfTheSnark?, in which Rule 42 says, "No one shall speak to the Man at the Helm". The Bellman completed that with, "and the Man at the Helm shall speak to no one." Thus, we can safely expect you to say what you have said, which is appropriate in many a coaching situation. -- cheers, Alistair :-)

A beginner can't listen to the code and hear what it says. He needs to learn patterns (in the generic sense) of code quality. He needs to see good code (and, I suppose, bad) in order to learn to make good code.

A question, and I mean it to be a question, is whether patterns as presently constituted help with this. I think Beck's Smalltalk Best Practice Patterns do help, because they are very micro. I think GoF is more iffy, as the patterns and discussion get pretty big sometimes, and they may make big solutions seem desirable. MartinFowler's excellent Analysis Patterns offer the same peril, the selection of a big solution when a small one would do.

Because patterns embody what most of us have spent many years learning (and still often imperfectly), they are heavy with content. Yet good code is light, gentle, simple, clear, pure. The one doesn't always lead to the other.

I have no answer - I'm sure the answer isn't what Josh suggests (sarcastically I hope). The answer I've tried to use in my life is to read and know as much as I can, then swap it all to background and go simply. When I've managed that, I've done well. More than that, I don't know ... yet. -- RonJeffries

See LetPatternsEmerge

The answer to your question, about whether patterns help beginners learn to listen to the code, for me, is a resounding YES.

But we may have different ideas of what patterns are.

For me, patterns enable the creation of light, gentle, simple, clear and pure code. But you seem to think of patterns as heavyweight. Perhaps that has something to do with the presentation of patterns, particularly in the GoF book.

The GoF book is wonderful, but it is flawed in its presentation of the problems that lead to the use of patterns. The Applicability section tries to help with this, as does the Motivation section. But overall, I find that beginners don't sufficiently understand the problem till they see it in code. So in my DesignPatternsWorkshop?, I describe and show the kind of bad, ugly code, which could be a lot lighter and simpler, were it to use a pattern.

Take the Decorator pattern as an example. One can use this pattern to make classes simpler, by getting rid of stuff that barely gets used. If you study JavaUnit, you'll find that Kent and Erich use it for implementing a Repeated Test and an Active Test (a test that runs in a thread). Their use of this pattern enabled them to keep their Test Case class light and simple. But they know the problem of placing too much stuff in a class -- how it makes the interface large, makes the class heavyweight, harder to understand, and harder to maintain.

Beginners don't know this, yet need to. And it is the same with many of the other GoF patterns, and the larger patterns literature (particularly, some of the best PatternLanguages). Important stuff, which programmers need to know, and use wisely.

Thus, my argument is that patterns are just another important discipline within the XP umbrella of disciplines. And like all XP processes, patterns are best used when they are mingled with other XP processes. -- JoshuaKerievsky

This seems (to me) to be apples and oranges (so if I've dramatically missed the boat here edit away). To my thinking, patterns are tools to convey knowledge (prior art). They have been around as long as man has, but perhaps not articulated. Saying that patterns are or aren't part of XP is like saying that a particular language or OS is or isn't part of XP. -- Ted

You may be thinking of patterns in the generic sense, while I'm referring to specific PatternsOfSoftware, particularly DesignPatterns and PatternLanguages. -- JoshuaKerievsky

JoshuaKerievsky, you state on RefactorOrDesign: XP has helped me learn to use patterns judiciously. I think this speaks volumes. This is how patterns and XP intersect.

Whether the patterns are used in the end or not, if the programmers have a working understanding of the patterns, they share a vocabulary. This seems like the sort of thing that might make CRC sessions go much, much faster. -- EricHerman

I collected a list on extreme programming books at http://www.x-m-l.de/cgi-bin/amaread.pl?topic=Extreme+Programming -- Marc Schoenefeld