The value of delaying

Knowledge of the legacy system is often poorest at the outset of a project. If it is not possible to identify a reasonably small MDE one should consider a delaying tactic. Develop a peripheral function that can be used both with the legacy system and the system to be. This will give the project time to learn more about the legacy system and come up with better strategies to reduce the MDE. The biggest problem with a delaying strategy is selling it to the customer's management. They will have very strong incentives to start immediately with the core parts of a new system. The value of building a peripheral function is primarily indirect (risk reduction). The costs on the other hand will be up front since development of the core functionality will be delayed. There is also a cost associated with developing the function to work with the legacy system and later modifying it to work with the new system. The case for delaying is very similar to that of refactoring. Both entail an up front cost that brings long-term benefits.