Developers have been refactoring for years and will continue to do so, and in this regard, it is nothing new. But with the advent of new "agile" processes like extreme programming (XP) refactoring really rules.

Not so long ago, Robert Watkins, a senior Java architect for Suncorp-Metway, was working on a large and complex system development requiring loads of integration when it became clear that some underlying assumptions were proving to have been just plain wrong.

A reasonably common experience whenever there are unknowns prior to development, the discovery was nevertheless a real inconvenience: It meant the company would have to make significant change to a large part of the underlying application if its performance was ever to prove satisfactory. In many organizations that would have meant either undertaking "major surgery" or living with the problem because the cost of fixing it was seen as prohibitive.

At Suncorp-Metway they know just how to make those improvements without taking the system offline and without dropping all other programming work.

"What we did over a period of time was to introduce several 'refactorings' to isolate the performance problem and let us put in a functionally similar piece of code that happened to run a lot better," Watkins says. "It took about two months to do, because we had to keep the system working and we couldn't drop everything we were doing, but at the end the system was actually functional because the speed was acceptable. If we hadn't solved this we wouldn't have got the system into production."

Watkins, an application systems specialist in Suncorp-Metway's J2EE Centre of Excellence charged with promoting industry best practices in development, says whether or not his organization actually refactors varies from project to project. Officially the group has been behind refactoring for about nine months.

"Refactoring is all about changing code without changing behaviour," says agile programming expert Dr Neil Roodyn. "You don't expect to get extra features from doing it; you do it to keep the code maintainable. Refactoring is like keeping the workshop tidy; it enables you to work in a clean and tidy environment."

But refactoring can also be a low risk, incremental development methodology that can save businesses money by helping them build on existing infrastructure and experience.

ThoughtWorks chief scientist and software development guru Martin Fowler describes refactoring as a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behaviour. At its heart, he says, is a series of small behaviour-preserving transformations (refactorings), each of which does little on its own but which put together in a sequence, can produce a significant restructuring. "Since each refactoring is small, it's less likely to go wrong," Fowler says. "The system is also kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring."

Most organizations struggle with "worn code": Code that has been modified, extended or truncated to suit changing business requirements, until the integrity of the original design is lost and any documentation rendered useless. Refactoring the code can be a useful and relatively painless way to address the problem. In fact some development technologies, such as extreme programming, depend on it (see "Sabre Takes Extreme Measures", page 118). And refactoring comes with significant business benefits. Organizations that refactor existing software can better leverage IT investments and reduce the risk inherent in further additions to software in the future.

"While the structure and code has been modified, the user should not see any difference in the system," says Colin Garlick, senior trainer at Wellington, New Zealand-based Software Education. "As such, any tests, whether automated or manual, should be able to verify that the functionality of the system has not been changed." He points out that software developers have been doing refactoring for years wherever an existing system needs to be modified in response to new or changing requirements but the structure of the existing system does not facilitate the required modifications.