Wednesday, July 07, 2004

FDD and Legacy Code

I’ve been asked by a few readers to comment on how to use FDD with a legacy code base under maintenance. [There is an assumption in this post that the legacy code is still OO in nature such as a monolithic 1999 vintage EJB system]. This topic has come up at Jeff De Luca’s web site in the past - Maintenance & FDD. Daniel Vacanti and I have had a couple of experiences with FDD on legacy code bases over the last 5 years and my general advice to anyone undertaking a maintenance process and wanting to gain the benefits of a method like FDD, is that they should try to make as few changes to the FDD process as possible. FDD definitely works with maintenace projects. So how do you go about it?

First off - make a consensus decision that you want to move forward with FDD and give people time to mentally adjust to what that means. Adopt a norm that “We will adapt what we are doing to the FDD process.”

Next, consider the new maintenance requirements and work through the 5 steps - build a domain model (in color preferably), then create a Feature List and plan the project by the groupoings of those features. This is the basic Coad Method as described in Peter’s 1995 and 1997 books Object Models - strategies, patterns and applications. This should not change. The domain model provides the foundation for the communication mechanism in FDD. It provides the foundation for the quality assurance mechanisms such as design and code reviews.

So how do you reconcile the new model with the existing code? This seems to be the mental hurdle which causes many architects and developers to recoil and believe that FDD can’t be made to work for them. There are two strategies for this.

(a) Legacy Wrapper Facade

Take the legacy system and effectively end-of-life it by wrapping it in a facade of service calls, i.e. make an API for the legacy system. This isn’t always appropriate. It really only works when the new maintenance work is on the periphery of the existing code base. The new FDD system will talk to the existing system through an SI (System Interface) layer. All the features for the legacy wrapper and the SI classes in the new system would be listed on the feature list as SI features.

(b) Refactor the Model

Using a tool such as Borland Together generate a model for the existing code. Take that model and print it out - however, large! Then with a small team examine it and try to identify class archetypes and color them. Take the model for the new iteration and map it against the existing model and identify areas for refactoring such that the new classes will “fit” with the existing legacy. Write a feature list for the refactoring.

In both cases, there is a bucket of features allocated on the feature list for reworking the legacy. There is clearly a cost to this. Why is it worth making this investment?

It is assumed that the new code built with a Coad style domain model will be more robust, easier to maintain, more accepting of change, more flexible and ultimately the enabler of sustained momentum and higher project velocity in future iterations. You are paying now for improved velocity later. By surfacing the refactoring or system interface features, you are providing transparency into the process. It is then possible to make an informed and objective decision about whether the cost is worth paying.

[Martin Fowler discusses the re-write versus maintain and refactor approach in Strangler Application which appears to offer us some design strategies which would be compatible with color modeling. Fowler’s Events are Coad’s Moment-Interval archetypes whilst Fowler’s Assets are Coad’s Party|Place|Thing (green) archetypes.]