Mere minutes after I posted on “architectural refactoring,” Keith Nicholas has commented about the unsuitability of the term. He said:
you'd be better off calling it "evolutionary design"
The dilution of the word refactoring is disturbing, there's a certain rigor to "factorization" which shouldn't destroy the product.
refactoring != a cool way to say "I'm gonna change stuff"
There’s a fair bit to be said on this, so I thought I’d add another post rather than try to reply in an undersized comment box.
I agree that the use of "refactoring" in this context makes me a little squeamish. Keith is absolutely right that there's a lack of rigor here -- partly because the scope of the changes ensures that enough changes that this isn't really a refactoring in the Fowleresque sense.
However, as Fowler defines it, "evolutionary design means that the design of the system grows as the system is implemented". In the case I'm describing, the design isn't growing. Rather, suboptimal design decisions are being rethought, reworked, rebuilt. In an evolutionary sense, I suppose you could argue this is "growth," since the new architecture is "fitter" than the old.
However, to my mind, the word "evolutionary" brings with it a connotation that the improvement is a small forward step, building on what is already there -- not a massive reworking of the underpinnings of the architecture.
The scope of this effort is what's a little unusual. Kyle Baley, for example, talks here about architectural changes and how you know when it’s time to start over. Now, Kyle is a fellow Canuck and an all-around decent fellow. I even agree that, from what he describes, they made the right choice. However, he describes an effort that was scoped at a maximum of 2 developer-weeks. I had on the order of twice as much time personally into proof-of-concept for the changes that were made; all told, we invested something like 120 developer-weeks into the changes.
I have trouble calling a step of this magnitude “evolutionary.” Perhaps architectural renovation would be a more apt term.
(And, as a minor aside, when I said earlier that “I’m not even leaving the functionality intact,” I should have been clearer. The original architecture made heavy, brilliant and infuriating use of refactoring. That trait, among others, were ripped out. After the renovation, the code base had been reduced by close to 40%, and virtually every line of code had been touched, or at least inspected. However, the business functionality remained essentially unchanged – essentially, since we were able to identify and remove a fair number of bugs during the process.)
Thanks for keeping me honest, Keith – and for the great point you made.