While working on an Analytics platform, I approached my manager about some of the older pieces of analytics. A section of code known for its complications and quirks – written by people no longer present at the company. I had been tasked with isolating this rather large stack into isolation – and it needed a name. I suggested Legacy, and was surprised by how quickly that idea was turned down. He explained his reason to me – but now I get ahead of myself.
A phrase often heard and acknowledged throughout development is that, “naming is hard”. He we are a collective lot of somewhat intelligent people, and yet we stumble at naming things. Maybe this is because “Engineers can be weird“. Maybe Shakespeare has been misrepresented by one of his characters on the smell of stink-buds. Maybe naming is hard, just because of what it represents. Which still leaves the question, “Why can’t I call it legacy?” Without further ado, here are different stages of ‘legacy’ and some ideas for names.
Stable: not likely to change or fail; firmly established. – Oxford Dictionary
Replacement plan
Needed
You’ve identified old code. It’s massive, it’s unwieldy. It’s still your main core code, but it doesn’t change much anymore. I’ve seen code at this point referred to as stale – but try to avoid that. Instead, call it stable – because that’s what it is. Calling something stale has strong negative implications. Now, inside your development group – you’ll know what’s wrong with the code from a technical perspective. And calling it stale implies those ‘wrong’ things are not getting cleaned up. But let’s say that term spills out of engineering. Will this I instill business wide confidence in development engineers? No. It will most likely invalidate developers because they produce stale things. Calling it stable will show that things can be built to last.
Deprecated: (chiefly of a software feature) be usable but regarded as obsolete and best avoided, typically due to having been superseded. – Oxford Dictionary
Determined
That old code that has been sitting around? “Old Busted”, we’re going to use the “New hotness”. Unfortunately – this is a common point where “Old Busted” is referred to as deprecated. This is where the first portion of the definition of deprecated is used. What is really needed before we can call it deprecated is the actual replacement. So again, keep calling it stable code. This will bolster morale for anyone still working on it – whereas calling it deprecated will cause developers to head for the hills. Calling it legacy at this point also has the same effect on developers. Who wants to care about something going away? Well, the people keeping track of the money do. You want everyone to care about the old code – until the point it is truly gone.
In progress
“Old Busted” is shrinking. It’s almost getting to a manageable place – there’s still a dev or two working on it – One might think now is the perfect time to call it legacy code. But it isn’t. In fact – don’t call it legacy until it is gone. At this point, there are areas that can truly be called deprecated. The “New Hotness” has in fact replaced the old in a shiny new ways. But it likely hasn’t covered everything at this point. Continue to refrain from using negative connotation description of the stable code.
Completed new work
The new code is dev complete. A lot of it is out in production – there might be a few dangling deploys. The A/B test is still in progress – but the new is clearly taking out the old. Now is a time to party! Call the old code deprecated. Refer to it as legacy – revel in the victory. Then summarily delete the code base and forget it ever existed. It’s what we do. It turns out, pretty much anyone can write a line of code – but removing old lines of code that are no longer relevant. Or even the ability to identify them. That is true skill.
Summary
It isn’t the end of the world if you call something ‘dead’ before it’s dead. Everyone will go along with it. But, do you really want to make good devs suffer for maintaining the bottom line? Or decrease the already small amount of trust business folks have for devs? (Maybe a future article about smart, untreatable, developers?). In the end, the words we use to communicate convey context. Personally – I’ll take a positive context spin over a negative one every day.
I Wanna Be The Dev 