Refactor Or Design

Continued from ExtremeValues

To me, this is both wrong and revisionist. The wrong part is that if you say that Design is vital to software development, all the heavyweight designers in the world will say, "Great! I told you we needed to spend 3 months/years in up-front design!", when what you want to say is "Don't spend 3 months/years in up-front design, because you can afford to change it." So I think that you don't believe it, and I think that others will get the opposite message of what you mean. Your book is called "Embrace Change", not "Embrace Design".

The revisionist part is that it goes against most of the discussion we have seen on wiki over the last two years. I sense that you are reacting to the "XP doesn't do design" sentiment that built up here over the course of the first year (I recall writing, but can't find my sentence about, "I'm sure Kent really does think before he types"). But to me saying Design is one of the four key activities, is an overreaction, one that doesn't represent what you have lectured on and coached on. I think the better correction to make is to make it clear that design occurs on a micro- or nano-level, and fit that into the story.

My reading is that Refactoring is THE key activity that underlies XP, and the one that distinguishes it from all other methodologies.

On ExtremeProgramming, you wrote " Listening, Testing, Coding, Refactoring. That's all there is to software. Anyone who tells you different is selling something. --KentBeck". That is a strong and defensible statement, and you and Ron have been defending it successfully. I can't see you changing it now.

My more than two cents worth -- AlistairCockburn

As long as we buy the idea that TheSourceCodeIsTheDesign, and that design is an activity that can happen in connection with code (a design representation), then design is there. But it may be too much of a stretch to the rest of the world to have it there so saliently. I wish that the word design did not have all of the diagrammatic and process baggage that it currently has. On balance, to me it would be nice if XP were able to redefine design by example. "Hey, we are doing design, anyone on the team can explain the design. The code is our blueprint and the tests are our specification. We have this wonderful machine that manufactures software from our design every time we press a button." -- MichaelFeathers (actually, I think that sounds a little more heretical than LTCR. Umm.. better not to say it.. just then by example, yeah, by example..)

We have no choice but to give our software shape. Whether we do it earlier or later does not change this. Software without coherent shape dies. So design, in whatever form it takes, is absolutely essential to producing software.

The intent of the four activities is to reduce the scope of what the methodology needs to cover to only those activities that are essential. Design is clearly one of those activities.

There is a difference between changing the way we say things because we are afraid of what others will think and changing because we have found a more precise description of what we think. The change in this case is the latter. --KentBeck

This is really two issues: putting Design on the list of activities; and removing Refactoring from the list.

Refactoring is critical! Please don't drop it!

As for Design, listing it as an activity may give the wrong impression that it is solely a separate activity. Granted: some Design work occurs as a more or less standalone activity (brainstorming metaphors, doing a brief carding session before coding). But most of the Design occurs hand-in-hand with Coding. Is there a good word that ties them together? Building? (Hmmm, no.) Crafting? (Hmmm, maybe.) Is this even a fair argument? After all, we Listen to our code and we let Tests drive our code. --KielHodges

Designing is better. The four activities are common to all software development and anyone can recognize them. When you then apply the four values the extreme programming methodology falls out nicely, and includes actively refactoring. --DonWells

"Design" as an activity is the process of creating a design. In XP, the real design is created as a process of refactoring. Thus, refactoring is more than just removing cruft from code, it is how you create your ultimate design. So, in the context of XP, I believe that "refactoring" and "design" are synonyms.

The problem is that they are not synonyms outside of XP. So, is it better to replace "refactoring" with "design" to make people feel better about XP initially, but increase the likelyhood that they will misunderstand things, or should you stick with "refactoring", get the Big Design folks mad and watch them leave, but make sure that those people who claim to be doing XP really are.

By the way, I have a slide that says that in XP the software life-cycle is

Maybe this is radical enough to wake up the Big Design folks!

-RalphJohnson

Ralph, I like that one whole hell of a lot and will use it with your permission. You're right, the names are only important when you're presenting, and then you want to make the thing as easy to swallow as possible. The real question is "how do you do design?". The BigDesign school says, "through experience and foresight". XP says, "by simplifying a working, testable system". --PeterMerel

Nice slide, but how about Redesign? That gives both a sense of not starting from some clean sheet, but also that it's a purposeful activity that produces a design. --SteveFreeman

As Ralph has it, one would presume there must be some twist to it (and hopefully try to learn more). With Redesign there are many that would "know" what it meant and object without really understanding.

Alas, XP (like many revolutionary ideas) doesn't fit commonly understood terms very well. Which is to say that "shorthand" terms without further explanation are bound to confuse those new to the ideas. So you can invent new terms , use terms such as "refactor" without a lot of baggage and perhaps not very widely understood, or use a term in a surprising way as Ralph has done. --KielHodges

Kent, if your sole motivation is truly precision then you've taken a gigantic step backwards. 'Design' is decidedly less precise than 'refactoring'. XP as advocated here has four parts to its process, and within micro-iterations, they always go in order: You listen, you write tests, you write code until the tests pass, and you refactor. You can't write a test before you listen, or code before the test, or refactor before you have any code to edit. This has been absolutely straightforward and simple to understand, however controversial it may be.

Are you now saying that you do design only after coding? On many pages there are quotes from most or all of the XP-advocates to the effect that design permeates the process, that XP isn't anti-design because Listening, Testing, Coding, and Refactoring are all designing processes. What happens to this stunning insight with your new definition?

(As for the presentational aspect of the change, I find that suggestion bizarre. If in fact the rationale is that changing the word from 'refactor' to 'design' is a soft-sell device, a cosmetic alteration to XP to keep BigDesign folks in the room during the show, please say so directly. I'll add specific arguments against that, too.)

This change absolutely staggers me. I'm embarrassed to say it, but the truth is it makes me downright shaky with stress! Please reconsider, please offer a more complete explanation. -- MichaelHill

Take a deep breath. Now, let it out. Okay. Here's the deal. Before we can start to explain what XP is, we have to describe the problem we are solving. We need a software development process that structures the activities of software development in harmony with a value system. What are the values? The ExtremeValues. What are the activities (and remember, these are the activities that are common to all software development, whether done extreme or not)? The answer I came up with is

Now, we know that the above activities do not suffice for programs that have to live a long time. What else do software developers (not ExtremeProgrammers, but all software developers) have to do? They have to provide some physical structure in which the logic of the system can live and grow comfortably. And we call this activity...(remember, your answer has to be universal, something that Grady would sign up to, something that Mellor would sign up to).

--KentBeck

I think the trouble here is a tension between your succinct statement of XP activities (which has to emphasize refactoring - or do you intend to rename the RefactoringBrowser the DesigningBrowser??) and your flag waving in the "anyone who says different is selling something". If one of these has to go, it should be the flag waving. But maybe neither has to go.

In fact I don't want to give up either. I tried Ralph's formulation yesterday when chatting with a group new to this stuff, and got the same reaction twice: "If you test before you design, what are you testing?" This led to the response, "If you don't know how to test, you're not ready to do design", and then a very conclusive discussion of differences between XP and BigDesign. I don't think that discussion would have been so fruitful if I'd had to explain what refactoring is. I think it would have been more like DoesXpDoDesign.

So I'm reluctant to jettison either term. If Refactoring is a way to do Design, CRC is a way to do Listening, StarUnit is a way to do Testing, and PairProgramming is a way to do Coding, then I think we can be clear on this: Listening, Testing, Coding and Design are all there is to software, and CRC, StarUnit, PairProgramming and Refactoring are all there is to XP.

Hmm. They're not all there is, though, are they? Which of the famous four activities do UserStories and ExtremePlanning fall into? --PeterMerel Listening, too?

If design suggests altering the logical and refactoring suggests altering the physical, with both being the product of listening, Refining (Refigning) comes to mind. This term is not overloaded, seems to encompass both, and still expresses sharpness, intent and frugality ...?

-- RodneyRyan?

It depends on what you're saying, in what context. If, as Alistair is reading it, you mean "to create software, all you have to do is listen, test, code, refactor", then it's better that way. If you mean "the essential components of software development are listening, designing, coding, and testing," then it's better that way.

I think it's more vivid the first way, and more what was meant in that context. I'd put it back. --RonJeffries

In with the good ....sssssssssnnnnnnnnnnooooooooooorrrrrrrrrrrrrtttttttttttt....

Out with the bad ....whooooooooooooooooooooooossssssssshhhhhhhhhhh...

Even though the new meds are really kicking in, Kent, I think I need to stand my ground. Ron's previous two paras exactly express my view. -- MichaelHill (Not, by the way, in denial about the fact that it's Kent's system and he can use any damned word he chooses.)

"Design" is often thought of as the process, not the result. A design is the structure of the code. Another name for this is "Architecture". If you want to indicate that structure is essential to software then the term Architecture may be better than Design.

-- DaveWhipp

A key word here is "feedback". Design + Feedback = Refactoring. If you don't refactor, how can you incorporate what you've learned back into the design?

Analysis/Test/Code/Design looks wrong because that last step is a feedback step. The design is actually happening all along the way. It is right in that until the last step is done, the design isn't finished. -- DaveHarris

So Refactoring emerges by combining both the values Listening and Designing, doesn't it?

See ArchitectureAnalysisDesignBullshit.

I see, its like ReadyFireAim. -- JohnClonts

As I see it XP has the following:

You have to explain of course, that this takes place in very short cycles. But I would say you have to add that explanation anyways. Refactoring is different from design. You may call it a special form of design. But I think it's crucial to XP to refactor and not just to do design as everybody else does. To make this distincion clear, you should also give it a different name. And besides, refactoring can be explained with a few sentences and then it's clear for everyone. Just my humble opinion. -- MalteKroeger

Wow, what a holy war!

This debate reminds me of the difference between theoretical physics and experimental physics. If I understand this right, BigDesign is like theoretical physics in that it is concerned with devising models. XP is akin to experimental physics in that it uses apparatus (code) to continually test and refine models. Perhaps the issue is not design vs. refactoring, but experimental coding vs. coding to a BigDesign spec.

I'm new to this site and as well as XP and patterns and I think you guys are definitely on the right track. I've done a good deal of OO and procedural programming over the years and I have to say that the term refactoring doesn't do much for me. It sounds more like a high school math problem than what I think you all mean by it ;-)

Thought you might want an outsider's perspective. --Alexander Ginos

I'm very disappointed. Seems like Refactoring was renamed Design for purposes of being "accepted" by traditionalists. If TheSourceCodeIsTheDesign, then when you RefactorMercilessly or Code, you're automatically designing.

Also, language is VERY important for meaning and understanding.

The fish trap exists because of the fish. Once you have gotten the fish you can forget the trap. The rabbit snare exists because of the rabbit; once you have gotten the rabbit you can forget the snare. Words exist because of meaning. Once you have gotten the meaning you can forget the words. Where can I find a man who has forgotten words, so I can have a word with him? - Chuang Tzu, fourth century AD

If we use a generic term like Design, then we're losing some of the meaning and beauty of Refactoring, since Design is not Refactoring.

For me, ExtremeProgramming will always be ListeningTestingCodingRefactoring. This bit of Refactoring the ExtremeProgramming Lingo is a step backwards. A shame.

-- BurtonKent?

After I submitted the above, I realized something.

Kent said ListeningTestingCodingRefactoring. That's all there is to software. Anyone who tells you different is selling something. --KentBeck

Now he's telling us something different. What are you selling, Kent? :-)

-- BurtonKent?

I don't think he's telling us something different. He's just using different words.

For a long time I agreed with (it seems) most of the people here, thinking that Refactoring was better than Design as one of the four essential components. Then I looked back on one of the times I was trying to explain extreme programming to someone new:

At this point I was enlightened, and remembered that before I found Wiki, I did not know what the word "refactor" meant in the context of programming. So now I agree with KentTheBeck.

-BrettNeumeier

Try saying "change the code" next time your audience hasn't heard of refactoring. Then your meaning stays the same.

But if you say, "and then you have to design the code", I'll bet you apples to oranges you will Really lose your listener.

This is a darn good debate for the XP community. Let's welcome it. Fact is, we've yet to sufficiently focus on what Kent calls SHAPE.

above, Kent wrote:

We have no choice but to give our software shape. Whether we do it earlier or later does not change this. Software without coherent shape dies. So design, in whatever form it takes, is absolutely essential to producing software.

At the heart of a system (I recently worked on) lies the Builder pattern. The Builder made it into the design because the software needed to run on a desktop or on the Web. Builder was a perfect fit. It's addition to the system was the addition of SHAPE.

Now, the consultant who suggested using a Builder was helping a team with little OO experience. They needed help.

So would it have been better to have avoided Builder, in favor of some far simpler (perhaps uglier) design, that could eventually be refactored to use Bridge?

Most XP people would say "yes" - start simple, and refactor mercilessly.

Ofcouse, you'd have to know what a Builder is, if you'd ever expect to refactor to it (and last time I checked, there wasn't a ReplaceWithBuilder? catalog refactoring to guide the uninformed).

So maybe teams which don't know Builder will refactor and refactor till they have something more and more workable, but which still isn't nearly as simple and good as a Builder.

That seems kinda foolish to me.

Patterns have helped me be able to design better, simpler code. They've also made me see how one can misuse them to produce overly flexible and complex code. XP has helped me learn to use patterns judiciously.

And I would argue that patterns and SHAPE have a lot to do with each other. --JoshuaKerievsky

Perhaps Shaping (as in shaping the code) would be better than Design(ing)? EirikMangseth

Kent, do you really consider refactoring and design to be the same thing? I always considered refactoring to be a specific kind of design -- not all of it. Traditionally, and you may be using it differently, refactoring did not add new or change the behavior of existing features but, instead changed the way in which those features are implemented. In other words, it doesn't design the what but the how. So, in this way, refactoring would be akin to low-level design (or code-specification) but does very little for high-level design (i.e. ArchitecturalStyles and/or SystemMetaphors). --RobertDiFalco

Now [2005] I humbly disagree with myself [1998] above. In fact I declare my former self a naive young pup. RefactoringIsNotDesign. --PeterMerel

EditText of this page (last edited June 27, 2005) or FindPage with title or text search