Strangling Legacy Code

Introduction
The dot com boom generated a lot of web applications that suffered from poor architecture and design. While these applications may function as required, they are difficult to maintain and extend. Though only a few years old, some already may be considered legacy code by the organizations that maintain them.

Organizations saddled with legacy Web applications often rewrite the applications from scratch—an expensive and even risky proposition.What if an application could instead be rewritten a bit at a time by the same team that maintains it?

This article is partly a case study of work done on my own team's application and partly a catalog of techniques you can try on your own project. Our application is a financial record-keeping product. End-users interact with it over the Web, communicating with servers running at our site. Note that our application is a Java-based Web application, but these ideas may work for other environments.

Strangling Defined
Well-known author Martin Fowler coined the term "strangler application" in a Weblog entry on his site. The term is taken from nature: A "strangler vine" establishes itself on a host tree and over a period of time slowly engulfs the tree until the tree dies and only the vine remains.

In the development world, the analogy is clear: A new application overtakes a legacy application a bit at a time until the old application no longer exists. Depending on your situation, this technique can be much more attractive and practical than a "rewrite from scratch" approach.

The Strangling Attitude Know Your Goals and Values
Strangling is an opportunity to change your development culture. Therefore, before strangling an application, you should have your goals and team values figured out.

Much as a company uses a vision statement to direct corporate decision making, your goals will provide decisionmaking guidance as the project progresses. At any crossroads in the process you should consider whether a given decision would bring the project closer to its goals.

For us, the primary goal is "agility, leading to competitive advantage." We need to stay ahead of our competition, and if we are held back by a limiting architecture, it is counter to that goal. From this we derived subsidiary goals, such as "promote testability," "increase flexibility,” and "decrease complexity." Thus, a given project decision or approach should promote one of these goals.

Your team's values determine how team members carry out day-to-day activities. We take a "pragmatic, not dogmatic" approach to Agile development, as follows:

• Pairing is encouraged, especially on difficult or key code
• Test-driven development (TDD) is preferred
• Avoid rules; use guidelines and judgment
• Value openness and a willingness to change approaches and refactor code
• Quality before development speed
• Strive for continuous improvement
• Testing is key

While we are not dogmatic about most things, we make an exception in the area of testing. Testability is a core value of the team, and our testing team does a great job of reminding us of that fact! Any piece of strangler code has unit tests, FitNesse tests (FitNesse is a free Web-based acceptance testing tool), and UI tests if applicable. When we touch legacy code, we make an effort to introduce tests although this often can be a challenge.

Stay on Course
Our high-level development directive is to develop all new features in strangler code while "pouring" existing functionality from the legacy system into the new architecture.

We always knew this would occur in fits and starts. Our metaphor for this is pouring a thick milkshake from one container to another: Sometimes there will be a smooth flow of smaller changes or new