Few organizations have a formal refactoring program in place, and Suncorp-Metway is no exception. Rather, Watkins says, refactoring is viewed as a normal part of the development process. But he says for refactoring to be successful, the organization must foster an environment where the practice is encouraged.
"A lot of places will have a focus where they put in a piece of functionality, and then they say, okay, I'll just move on to the next piece," he says. "The problem with that is that over time, the code becomes rather inflexible. By using refactoring as one of the steps to keep code clean and flexible, you improve your overall productivity even though each individual step looks like it has taken longer because you are taking this time to clean up."
Doing so, he says, also helps overcome problems with understanding code. Where code is hard to understand, Watkins says, whether because it was poorly written or the documentation related to it is confusing, then refactoring makes it easier to understand. The emphasis is on a series of safe transformations. "That's one of the key differences between refactoring and other forms of redesign - that it is meant to be safe," he says. "You're not meant to be changing anything, you're not meant to be breaking anything, it's really just rearranging the code to make it easier to read."
To keep the process safe, organizations should refactor using a series of "test harnesses" and test code - major conditions necessary to prevent human error. Without the solid test harness, organizations may find themselves introducing bugs into a clean system, he says.
"Refactoring gives us the benefit of continuous improvement of our code base," says Brad Long, development manager at Oracle's Australian Development Centre. "However, to ensure code still meets its requirements since making changes to working code can be risky we couple refactoring with a comprehensive unit and system test suite. Our development team uses a continuous integration environment (continuous code compilation) and has in excess of 4000 unit tests which run daily against our product."
Long says such unit tests are critical to code quality and allow developers to use refactoring with confidence. Without the unit tests, he would not recommend anything but carefully planned refactoring or reworking of projects. "In a nutshell, refactoring gives us the benefit of continuous improvement - not necessarily driven by external requirements - but you need the testing infrastructure to allow refactoring with confidence," he says.
Organizations should also encourage refactoring for "migration projects" when systems reach the end of the lifespan on an existing platform and have to move to a new one. William Scheer, chief operations officer of TurnAround Solutions, a systems developer with headquarters in Sydney, says his company has done a number of migration projects after systems had reached the end of their life on a particular platform or system. "What that requires is looking at the existing code bases, and either rewriting based off of that code, or refactoring that code and redeploying," he says.
Refactoring is also helping the company with a major project involving the taking over of an existing system from a supplier and redeploying and improving its maintainability and supportability. Scheer says that is a major business benefit of the practice, which should generally be seen more as an operational efficiency driver than a growth driver. On the other hand, where refactoring is used to refresh system requirements it does give the organization a chance to look more critically at the way a system has been structured, and if changes are needed, a way of using those changes as a path to access new markets.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.