skizz.biz

I have been involved in a few discussions recently about the difference between refactoring and rewriting. And it got me thinking about the ways we characterise what we do.

On most of the projects I have been involved in we have talked at standups about the refactorings we do, in particular those that affect other developers. Often these are in response to new requirements that mean that a part of the system needs to be more flexible.

This is also useful information for the customer or BA, since it means that stories and tasks that concern that piece of the system may suddenly become lower cost, and this may change the sort of stories they think about for the system.

So I think it is entirely appropriate and necessary to talk about these refactorings in a stand-up.

But what is a refactoring? My last project was an invoice workflow system. The first release had a single invoice type and the workflow was defined in code and spread throughout the system. In the second phase (when I became involved in the system) we added 6 new invoice types to the system, each with their own slightly different workflow.

In one iteration we had a collection of stories that were estimated at about 50% of the entire iteration. We had wanted for a while to change (I am specifically avoiding the term refactor here - bear with me) the system so that the workflows were driven form some kind of definition file, and so we said at the planning game that we would put all these cards in one pile and one pair would work on this change.

Note that we didn’t write a separate card for the story. We chose to take the time from real stories. I have always found this to be better than separate cards since it means that you have a stopping point — when the story is complete — and have less tendency to keep changing the system beyond what is required.

We took the same time as 2 of the cards to implement an XML file to drive the workflow. and the rest of the stack of cards then became (literally) a 10 minute job of editing the new XML file. We also spent a short amount of time writing a simple DOT file to allow us to generate a workflow diagram. This became our primary tool for talking with our BAs and allowed us to discuss the workflow at a high level.

So back to the point: is this refactoring?

Many would say no, in the sense that it is a change to the architecture of the system. But all refactorings change the architecture at some level. Are two small refactorings a refactoring? Three? Four? Fifty? If the card takes one day and the build never breaks is this a refactoring? It can’t be the number of files changed, because a rename for an enumeration constant could change many files in different packages.

A problem in some teams with the term refactoring is a belief from the customer that refactoring is worthless. Since by definition you are changing code without changing behaviour, aren’t you wasting my time and money? Of course this is naive since we refactor to make change easier, so in the longer term it saves the customer time and money. But it takes an educated customer to realise this.

Many customers might reject the change — which we characterised as a refactoring — that I have talked about above. We were able to do it, and able to be honest about it, because we had gained our customer’s trust by openly discussing, delivering on and proving the benefit of smaller refactorings.

So whether you characterise these sorts of changes as refactoring or not is a grey area, and depends mostly on trust. If your customer is comfortable with it, call it a large refactoring. If not, call it a change or rewrite and you will need to spend more time justifying it to the customer.

This entry was posted on Tuesday, March 2nd, 2004 at 7:17 am and is filed under life. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.