Legacy Code

Legacy code challenges tend to induce the strong motivator of fear into even the most senior developers. Consider having to specialize a small part of a longer, untested function. Imagine that getting your feature implemented is a matter of introducing three lines worth of variant behavior in the midst of thirty lines. As an experienced programmer, you know that the right design would involve factoring common behavior to a common place. The template method design pattern represents one acceptable solution.

(Another solution would involve introducing a conditional. But that’s often a recipe for gradual decay, as functions become weighted down with flags and nested blocks.)

Yet, also from the stance of experience, many programmers resist doing the right thing, which would involve changing existing, working code. Perhaps they’ve experienced smackdowns in the past, chastised for breaking something that had worked all along. “It ain’t broke—don’t fix it!” They instead take the path of least resistance: copy, paste, and change. The end result is sixty lines of code instead of less than thirty-five. Being driven by fear creates rampant duplication in codebases.

The best way to enable doing the right thing is to have tests that provide fast feedback. On most systems, you don’t have that luxury. Michael Feathers, in Working Effectively with Legacy Code [Fea04], defines a legacy system as one with insufficient tests.

Working on a legacy codebase demands a choice. Are you willing to let the cost of maintenance steadily increase, or are you willing to start fixing the problem? With an incremental approach, using some of the techniques outlined in this chapter, you’ll find that it’s not an impossible problem to solve. Most of the time, it’s probably worth the effort to put a stake in the ground and demand no one allow the system to get worse. About the only time it’s not worth it is on a closed system or on one that you will soon sunset.