Refactoring Means Failure

A: "Methodology X reduces the need to change existing code."

B: "That's nice, but can it handle change 'A'?"

A: "Well...it can, but I'll have to refactor the code to avoid excessive repetition."

B: "But I thought you said that methodology X reduces the need to change existing code?"

A: "But refactoring doesn't count."

B: "Why not? Work is work."

A: "I don't know, it's just allowed."

The need to keep refactoring the code to avoid ugly constructs means that the code didn't handle change very well. It's a failure of the no-change promise if you ask me. I agree that surprise changes happen and one may indeed have to re-work the code design. That's just part of life -- we build abstractions to simplify our design, but new requirements often don't fit our existing abstractions and we have to undo or change them. However, to not count refactoring when analyzing change impact is not fair counting. --top

Refactoring is not about handling change. Refactoring is about improving code after initial development, in recognition of the fact that the first attempt at a solution is almost never ideal (or even necessarily acceptable) and that certain methodologies (TestDrivenDevelopment, for example) work well in conjunction with refactoring to produce sound systems.

Yes, but why is one "improving code" in the first place? Usually it's to aide in future maintenance, that is, code change. Thus one is changing the code to avoid changing the code? (And by the time you get it right after umpteen iterations, the language will fall out of style.)

[I grant the following statement: "to not count refactoring when analyzing change impact is not fair counting". Often, one will refactor the existing code (e.g. ExtractMethod) before making a change to improve it, rather than afterwards. (This is certainly easier to test.) That said, the 'RefactoringMeansFailure' title seems strong and inflammatory for this rather weak assertion. It also seems somewhat contradictory: the reason refactoring counts is because it is part of a successful change.]

"Refactoring can mean failure of change prevention" may be more accurate, but is too long. Maybe we can find some compromise, such as "Refactoring can mean failure"? I do agree that preparing for other changes is often the best time to refactor. But the extent of refactoring can still be affected by our earlier design choices.

[It is silly to talk of "failing change prevention" in the context of CodeChangeImpactAnalysis. I mean, you're already assuming a change was needed, and refactoring is often just a little more change, and it is quite reasonable to discuss the impact of 'change A' on a project that refactors religiously (i.e. following a strict ThreeStrikesAndYouRefactor rule) vs. one that duplicates code without remorse. As far as titles go, how do you feel about 'RefactoringIsCodeChange?'? ]

I'm primarily pointing out that people often talk out of both sides of their mouth when they claim a tool/technique/paradigm reduces the impact of domain requirement changes on code. They claim it makes "code easier to change" when in fact what they are really doing is redefining change under the euphemism "refactoring". If I have to change a lot of code when a requirement change happens, then the code didn't weather that particular change very well and we shouldn't make excuses for the code. The code gets poor marks for that change, period.

There are hundreds of pages on this wiki about refactoring, so there should be a good number of definitions around to argue about. WhatIsRefactoring looks like a good starting place.

CategoryRefactoring, CategoryChange