Editorial Note: I originally wrote this post for the SmartBear blog. Go take a look at the original here, at their site. If you like posts about collaboration, code review, and other topics, take a look around while you’re there.
Legacy code is sort of like your house’s storage crawlspace. It tends to be a repository for things that mattered to you in days past or on special occasions. The code sits there, largely unnoticed, until such time as an odd change or a production bug causes you to dig it up, dust it off, and revisit it. Barring extraordinary circumstances, it tends to sit, largely forgotten, and possibly rotting or getting riddled with moth holes.
By and large, this considered an acceptable and even desirable state of affairs in our industry. A lot of folks that manage software development efforts and hold the purse strings think of software construction the way they think of building construction. Once you’ve built a house, it’s done. Why would you go back and revisit it unless there was some kind of problem that had cropped up? The problem with this well-intentioned, bottom-line thinking is that building software isn’t much like building houses.
When you build software, you stack the new atop the old and everything comes along for the ride. Sure, there may be the occasional new module that stands all by itself or plugs in with the rest, but that’s the exception. The new code interacts with the old stuff, calling into it, relying on it, and running beside it in production. If housing construction worked this way, a short circuit in the house across the street might cause your shower to stop working.
The result is that, however well-intentioned someone encouraging you not to focus on legacy code might be, the edict is often misguided. If the short circuit across the street meant you couldn’t shower, would you listen to someone who told you their wiring was none of your business? Clearly, you wouldn’t go storming over there out of nowhere, remodeling that house, but you wouldn’t just ignore it either.
This is the approach required with legacy code in your code base. The fact that someone typed it out years ago doesn’t mean that it doesn’t have a very real, current impact on your team every time you deploy your code. Because of this, it behooves you to review it occasionally, when time permits.
Let’s examine some specifics as to why it makes sense to audit your legacy code from time to time. Having your finger on the pulse of everything going into production is a compelling but abstract argument. So, let’s get more concrete.