oftware systems rarely remain static once they are put into production. Most businesses undergo changes to their processes and so the systems that support them must constantly be modified to meet the new requirements. These changes are typically implemented as patches to the current system, with as little architectural redesign as possible. While this allows the changes to be implemented faster, over time the patches stress the system to the point where the cost of maintaining the system and implementing additional changes becomes exorbitant.
When that time comes, a major effort is devoted to rolling out a new system. This initiative must include a data conversion and sometimes a period where both systems run in parallel. Rolling out new systems is very expensive and carries its own risks of failure.
|Every programmer I know of has a list of things he would have designed or coded differently for every project he's participated in.|
But there's another factor, less often discussed, that also stresses our existing systems over timethat's the compromises that the original system's programmers had to make in order to get it out the door in time. Every programmer I know of has a list of things he would have designed or coded differently for every project he's participated in. The compromises often take the form of less elegant, flexible, or maintainable code. While these compromises win developers time up front with a quicker release, they cost us dearly over time, as it is becomes harder to add or modify features of the system.
Shifting the Plates
The pressures building up on our systems can be compared to the pressures that build up against the tectonic plates of the earth. If those pressures are released in a controlled and gradual manner, major disturbances are avoided, otherwise an earthquake occurs with all the associated damage. To solve the problem of code maintenance, we need a similar valve releasea process that will reduce the stresses on our systems intermittently, thereby extending their lifespans and reducing the costs of maintaining them.
|While the benefits of refactoring might be clear to programmers, it is not easy to demonstrate the business benefits of reengineering old code.|
The answer to this dilemma seems simple: a proactive system of gradual refactoring will keep systems running acceptably and should eliminate the need for a total system overhaul. First, we need to identify the areas that have grown difficult to modify or maintain. Then, instead of waiting for our system to become unusable, we will proactively modify these areas to improve their architecture and structure.
While the benefits of refactoring might be clear to programmers, it is not easy to demonstrate the business benefits of reengineering old code. Rarely will a business have the luxury or willpower of choosing refactoring over new development. (Microsoft recently said it would do exactly that; halting all new development in order to fix security-related structural problems in existing systems, but even still it has scheduled only about two months for the analysis of millions of lines of code.) Businesses are typically focused on the next feature set they require.
Therefore, in order to be successful, the refactoring process must work in tandem with new development initiatives. In fact, a synthesis of the two processes can produce a win for everyone.