Is It Worth It?

After working your way through the legacy code examples in this chapter, you might be thinking, “Gee, this is a lot of work. Why bother?”

You already know the cost of not bothering. Your system no doubt reminds you daily of the increasing pain caused by slow and sure degradation. Builds take longer, analysis time takes longer, tests take longer to run, and maintenance takes longer.

Using legacy code management techniques, including the ones overviewed in this chapter, you can turn a system around as long as you have the support and dedication of your entire team. Initial efforts will make only tiny dents in your codebase. But if everyone has the goal of making incremental improvement as they do their “real” work, you’ll start to see dramatic payoff in the areas of change. (How long? That depends on your system size, rate of change, difficulty of the code, willingness of the team, and so on.)

Your team must make a choice: either dispense with legacy system salvaging techniques and let the codebase continue to degrade (it will) or put a stake in the ground and decide to change direction for the better. If you choose the latter, help your team derive some ground rules that cover expectations around every bit of code checked in.