Analysis Is Refactoring

...but it would have been better to say it the other way around. I've pretty much rejected the PhaseIst definitions of analysis, including the "what versus how", the "discovery of requirements", the "most abstract design", etc. Really, the essential activity of analysis -- which is seeing a whole as its parts -- pervades all kinds of systems work, just like breathing pervades life.

When you refactor code, you're looking for eliminatable similarity which is somewhat hidden because of the way you composed things in the first place. So you start by 'breaking it down', and that's analysis. When things are broken down in the right way and to the right degree, it's easy to pick out the duplicates. Refactoring then proceeds with synthesizing upon the new set of essential elements. Analysis and synthesis are so commonly done together (we scarcely break them apart -- what irony!), that the latter term has all but disappeared from the vocabulary. So for that reason, I tolerate the use of the word analysis to include synthesis, although a real language purist wouldn't.

Refactoring carries a connotation of code with it, but other things can be factored or refactored. The terminology has really sprawled, as "factoring", "refactoring", "SeparationOfConcerns" and "decomposition" are all analyses, and all roughly synonymous. Did I leave any out?

Well, I seem to have refactored the software development lexicon here, but I'm not naive enough to believe that my usages will ever become mainstream. But since I am trying to influence, I'll go ahead and make my pitch. If refactoring and analysis are different, it's only by common usage and the context in which we apply them. Deep down, they are isomorphs. We have DriveByAnalysis and AnalysisParalysis, but no pejorative terms for refactoring. Why does refactoring seem to be the "good cop" of the pair?

When you refactor code, preserving function exactly, you're working within a bounded system, and that makes the job easier. When you analyze problems and their contexts, according to JerryWeinberg, you are really exploring unbounded space, and part of the challenge is to find reasonable bounds. This is much more difficult. That's why it's much easier to get satisfactory results refactoring code than it is analyzing problem space.

I consider myself an analyst (an exotic one at that), but I learned the basic techniques by refactoring code. That's a nice learning progression, starting with the easier task, but I didn't know it at the time. The "drive by" and "paralysis" syndromes are just derailings of a difficult pastime, but the notion of analysis in software development should by no means be forsaken, glitzy modern methods notwithstanding.

-- WaldenMathews

The possible problems of refactoring have been noted, but nobody has yet created a suitably pejorative wiki name for them. See FineLineBetweenRefactoringAndFutzing and CircularRefactoring for examples.

They do feel the same to me - in a sense. There's this knot and you are teasing it untied, pulling here and there, getting the shape of it, pulling bits through. Very much the same feeling. Except ...

In refactoring, these days, there are patterns. See this, do this, now it's better. It can be much more ... not rote, but somehow directed. Doubtless those patterns are there in Analysis - MartinFowler has given us many of them - but to me the analysis process is far less directed.

I should read MartinFowler. Also, Jackson has given us ProblemFrames. I like the "teasing the knot" analogy, but I'm not sure whether it applies more to "open" or "closed" types of analysis. It may be "open" in the sense that you've never seen a knot like that before, and closed in the sense that we all know what the solution looks like. --wm

See RefactorLowHangingFruit, http://www.xpsd.com/RefactoringDemo